Every developer knows that unit tests are a good idea. Most developers know that using version control is a good idea. Some developers know that a "one-click" build is a good idea.
As you walk the aisles of the programming section at a bookstore, or browse the online equivalent you’ll see knowledge galore. How-to, what-to, why-to out the wazoo. With all this knowledge so readily available, why aren’t there more good or great developers?
The Big Swinging Developer is rarely judged by knowledge alone. As always, you have to be at least "good", which involves knowing a thing or two, but it’s your beliefs that will set you apart from everyone else. I happen to believe in isolating changes/problems, repeatable builds, and testing. Because of these beliefs, I’ve learned a lot of techniques to help me practice them.
I’ve been working on a web app this Memorial Day weekend. I’m a development team of one. No one is watching me, checking up on me, or even working with me. I have a one-click NAnt build that deploys to a Virtual Machine and have been branching my releases in my hosted Subversion repository.
You practice your beliefs because you can’t imagine doing things any other way and that defines you as a developer more than any single technology or language ever can. So, what do you believe?
I have plenty of mantras: "Isolate changes", "Be repeatable", "Put yourself in the user’s shoes", and several others. These are things that I believe, practice, and preach. My battle cry, however, is something I actively pursue and defend. If someone isn’t isolating their changes or is failing to think about their users, I’ll probably say something. If someone is being unclear, I’ll definitely say something.
In Braveheart the battle cry was, "Freedom!". In Viking Quest it was, "Victory!". For me, it’s "Clarity!".
On page 48 of Career Warfare, author David F. D’Alessandro mentions the statistic that eight million Americans have IQs over 130 and that this makes smart people "as common in organizational life as bad coffee". Reading his thoughts on the subject reminded me of several ideas that keep recurring with my own co-workers.
Smart Isn’t Enough. As D’Alessandro points out, smart people are pretty common. Being smart is the cover charge and if you aren’t, then chances are you won’t get past the velvet rope. Some clubs have a higher cover than others – Google, for example. Once you’re inside, though, no one else who paid the cover charge is going to be impressed that you made it in.
Smart != Good. Being smart gives you potential. It’s how you use that potential that counts. If you are absolutely brilliant and create something that kind of sucks, it does not matter how smart you are. Stuff that sucks that was created by idiots is roughly equivalent to stuff that sucks that was created by geniuses. As a matter of fact, I might even have a preference for the idiot version since it’ll probably be easier to figure out and fix.
Smart Is a Vector. Most people focus on the magnitude portion of being smart and ignore the directional component. What’s worse is that they often apply the magnitude to arbitrary directions. Even worse than that is applying the magnitude to multiple directions simultaneously and start assuming that someone who is good at one thing will be good at a bunch of others simply by being "smart". This is dangerous before the fact because it sets people up for failure. It’s almost worst after the fact because it will be used to explain why something can’t be done, and therefore not even attempted: "Bob tried to create a distributed .NET app and screwed the pooch. Bob created something similar in Java and it was awesome. Bob’s very intelligent, therefore .NET sucks and can’t work correctly." Oy vay. How about "Bob sucks at .NET and, therefore, Bob should have either gone to a Java shop where he could flourish" OR "Bob should have spent a little more time getting smart in the .NET direction"?
You’re Never Too Smart to Be Wrong. I think that the most important thing that you can do to reach your potential and put your intelligence to work is to know yourself. Know what you’re good at and recognize when a task just isn’t for you. Let it go to someone who is actually smart enough (magnitude) in that way (direction) to do a good job. If the direction is something that you’re interested in, then pitch in so that you can learn something and take a bigger chunk of the work next time. Don’t, however, believe that since you’re smart that you’re universally capable. Don’t let others believe it, either, or you’re bound to wind up like Bob where no one can help/save you because they think (because they were repeatedly told) that you were too smart to be wrong.
Developers make more mistakes than any other profession I can think of. The editor you use finds some. Your compiler finds some. Your unit tests find some. Static analyzers find some. The QA team finds some. And, as we all know all too well, your customers find some.
I was recently talking to a friend and co-worker about developer mistakes and we reached a valuable conclusion: senior developers don’t make rookie mistakes. The result is that it appears that they make fewer mistakes, but the quantity isn’t what’s important. Senior developers don’t necessarily make fewer mistakes, they simply catch them sooner. No else sees the majority of their mistakes because of the way they perform their work. Senior developers know what it takes to deliver good software and at the critical decision points, they do what it takes to keep things on track.
Ask yourself: When was the last time you made a rookie mistake? If it’s been a couple of years (or a couple of projects), then chances are that you’re firmly in "senior-level" territory. If you’ve made any in the last few months, though, then you might want to spend some time focusing on the way you work instead of adding new tools or techniques to your repertoire.
, author David F. D’Alessandro mentions the statistic that eight million Americans have IQs over 130 and that this makes smart people "as common in organizational life as bad coffee". Reading his thoughts on the subject reminded me of several ideas that keep recurring with my own co-workers.