Alarming News: I like Morgan Freeberg. A lot.
Anti-Idiotarian Rottweiler: We were following a trackback and thinking "hmmm... this is a bloody excellent post!", and then we realized that it was just part III of, well, three...Damn. I wish I'd written those.
Anti-Idiotarian Rottweiler: ...I just remembered that I found a new blog a short while ago, House of Eratosthenes, that I really like. I like his common sense approach and his curiosity when it comes to why people believe what they believe rather than just what they believe.
Brutally Honest: Morgan Freeberg is an intriguing guy...[he] asks great questions and answers others with style, flair, reason and wit. On the blogroll he goes. Make him a part of your regular blogospheric reading. I certainly will.
Brutally Honest: Morgan Freeberg is brilliant.
Common Sense Junction: Misha @ Anti-Idiotarian never ceases to amaze me. He keeps finding other good blogs. I went over to A.I. this morning for my daily Misha fix and he had found this guy named Morgan Freeberg in Fair Oaks, California, that has a blog, House of Eratosthenes. Freeberg says its "The Blog That Nobody Reads" but it may now become the blog that everybody reads.
Jaded Haven: Good God, Morgan, you cover a topic from front to back with a screwy thoroughness I find mind boggling. I'm in awe of your thought proccesses, my friend, you're an exceptional talent. You start by throwing in the kitchen sink, tie in someone's syphilitic uncle, bend around a rip tide of brilliance and bring it all home in a neat, diamond dripping package of an exceptionally readable moment of damn fine wordsmithing. I love reading you.
Mein Blogovault: Make "the Blog that No One Reads" one of your daily reads.
Philmon: When Morgan meanders, stick with him - he's got a point and it'll be worth it in the end. He's not a hit-and-run snarky quip kind of guy. The pieces all fall into place like tumblers in a lock and bang! He's opened a cognative door for you.
Rightlinx: Morgan at House of Eratosthenes is one of the best writers out there. I read him nearly every day because he manages to provide an interesting perspective, even though I don't always agree.
Poetic Justice: Cletus! Ah gots a laiv one fer yew...
Was looking for a quote about what bad software engineers do, and I can’t even remember what it was I was trying to find…stumbled instead into this post from a year ago about what good software engineers do.
I’ve talked with a number of people, particularly business-type people, who seem to consider engineers working on side projects as a warning sign. This attitude, primarily held among non-technical people, is not only wrong but it actively interferes with their ability to find, nurture, and keep good software people.
Good software engineers almost always have side projects. In fact, those side projects are one of the reasons why they are good software engineers. The reason is simple: Good software engineering requires constant learning, and very few companies create a situation where all of that learning can occur on the job.
Technology, and software in particular, move incredibly fast. Today’s frameworks and tools are different than those of a year ago, and those are different still from those of five years ago. The details are ever-changing, requiring software engineers to be continually learning to stay afloat. At the same time, the techniques and practices that are used in software development, the deeper skills underlying the fast-moving surface, are consistent but require long and dedicated work to even begin to master.
This double requirement of keeping abreast of the latest tools and frameworks while at the same time mastering the underlying techniques means that in order to become and remain a good software engineer, you need to continually spend a tremendous amount of time learning. There are both requirements of breadth (keeping up to date with changing frameworks and tools) and of depth (improving your underlying skills), and it is very rare that learning on the job is sufficient to cover all.
Can’t disagree with any of this. I know better. I especially like that kick-in-the-chops at the beginning: “This attitude, primarily held among non-technical people…” Yes, that’s been my experience as well.
Wasn’t so thrilled to read about this: “…and the use of technology to accelerate social change.”
I’m sure he’s a good guy and all, and he’s definitely right on the money about the side-projects thing. My own observation about this has boiled down into a ripoff of the Glengarry Glen Ross monologue about Always Be Closing: Always Be Building. It is a lament rather than a lecture, in my case. I look back over the years and see I’ve always been surrounded by these well-intentioned sagely types urging me to not build anything, for one reason or another. It goes back to the very beginning. I regret every minute of every hour I’ve spend honoring that advice; it’s just not good advice. The “Always Be Building” thing, that’s better.
The dilemma that comes up is a vanishing boundary. In actuality, nobody’s ever told me “stop building things” because that would obviously be telling me to stop doing what I’m supposed to be doing in my job. The concern is about developing an architecture, protecting the code base, making sure nothing is committed that doesn’t properly gel with the architecture. Which is the very foundation of a good software engineering practice…right up until you get into that loop where, the whole team is waiting for an architecture to emerge, and there isn’t one emerging because you have these faux-architects wanting to “play architect.” They need to fiddle around with things before they can tell anybody what to do, because until they get that done, they just don’t know.
And that, of course, is a problem.
That can be people pretending to know things they don’t really know — or, it can be a natural outgrowth of what we used to call the “bleeding edge technology” situation. Meaning, since the whole development team has made it their business to confront an emerging technology, let’s say for example, supporting hardware that has just been developed and is offered to a narrow, specialty market — they’ve effectively removed themselves from the option of learning from others. There aren’t any others. So this isn’t architectural malfeasance. Yet. But the situation is the same: This narrow elite circle of “trusted,” not necessarily talented, coders start writing (bad) code as fast as they possibly can, in a quixotic attempt to try to make the unknown into a known, so they can come up with an architectural framework, and parcel out the work to these other guys who are sitting around waiting to be told what kind of code they should be writing. Who all have to be paid, regardless.
Or, maybe everybody’s trusted. That’s an ideal situation. But it doesn’t guarantee success, all by itself; and even there, you cannot count on the idea that your work will always be providing you with an optimal challenge. It all comes down to, your personal growth is your responsibility.
I think this feeds into a much larger debate, with well-informed and passionate opinions on both sides, among technical and non-technical people alike. Is the most effective development team a band of individualists, almost like bank robbers, who are in it for themselves, each bringing their own backgrounds to the project? Or should it be more like Star Trek, where team members devote their lives to the company construct just like Starship officers devote their lives to Starfleet…need a book? The company will provide. Weather getting nice? The company is having a softball match, see ya there.
I’m personally leaning somewhat toward the first scenario, with the bank robbers, although I recognize people need to communicate effectively in order to do an adequte job as a team. That is a hard requirement, but I think if the bank robbers act like professionals, it can be met without turning the whole organization into Starfleet with everyone running around wearing the same style of shirt and quoting regulations. The most successful teams I’ve seen, adopted a flexible, hybrid approach. We’ll have barbeques and softball matches…attendance not mandatory…buy the books, and we’ll reimburse you unless you have plans to stick your name and phone number on the inside cover and mark it up. (My current employer wouldn’t care about that, I don’t think, but I always buy my own because if a book is particularly valuable to me, it’ll end up getting torn to shreds.) But I think ultimately people favor one of the above two choices based on their personal politics. This guy is probably an exception, since his biography pegs him as a lefty. Most of the lefties I’ve met on the job, should they express an energized opinion about this, they’ll go the other way: No, the company owns what you do, lock stock & barrel, and you shouldn’t have side projects unless your manager has signed off on it, in which case you should be providing weekly status reports on it. Don’t care if you bought a media jukebox for your home movies and it was all loused up until you dashed off a three-line batch file to make it work right, on your home PC, at three o’clock on a Sunday morning — submit a report to your manager about that batch file, because it’s ours.
I’ve always been told you should think like you own the company. That advice is good, I think. If I’m the company, I do not want to own all the code any of the developers have ever written. New technology comes out, the developer pokes it with a stick, does whatever experiments on it he’ll be inclined to do, writes some crappy code to figure out how it works. After he’s familiar with its interfaces, he writes some better code. If I’m the company, I want to own that better, somewhat well-designed “I think I know what I’m doing now” code. I want to keep the wheat and leave the chaff behind.
Leave a Reply
You must be logged in to post a comment.