House of Eratosthenes

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.

Technology, and software in particular, move incredibly fast.

Which is why I stop short whenever I have this brain-fart thought about goin’ back to work. I DO miss it (work) from time to time, strange as it may seem.

More to the point… I preferred bank robbers, back in the day, and my teams mostly had those sorts. You prolly find that hard to believe, since I know your opinion of EDS, but yeah… they DO exist, or they did. I have no ideer about now, considerin’ EDS is HP these days.
- bpenni | 03/28/2012 @ 12:40
No, the “boys in the pit” came from all kinds of walks of life, civilian and military. They were disproportionately from around the beltway area, though…where I think there might have been a unique pressure applied to assume a “Star Trek”-like cultural atmosphere. But at heart, they were more of the bank-robber type. That other company though, known as “Big Blue”? From what I managed to see from the inside & outside, and read about, that’s another story.
- mkfreeberg | 03/28/2012 @ 13:56

Leave a Reply

You must be logged in to post a comment.

Recent

Items of Interest

Monthly Archives

What They Say

Links

“Good Software Engineers Have Side Projects”Wednesday, March 28th, 2012

“Good Software Engineers Have Side Projects”
Wednesday, March 28th, 2012