Friday, November 11, 2011

3 Simple Rules That Will Make You a REAL Superstar Developer

In my experience there are two kinds of "rock star" software developers.  There's the Neil Peart rock star developer, who combines a natural blessing of talent and intelligence with a relentless work ethic and humble attitude, and over time becomes the developer that people not only want to hire, but want to be.  And then there's the "prima donna" rock star developer, who combines a modicum of raw talent with sheer attitude and self-promotion into the programming equivalent of a hotel-room-trashing, sex-and-drugs-and-rock-and-roll tabloid icon (I won't name an equivalent musician--use your favorite example).

Last year a tweet by Zed Shaw pointed me to a brilliant piece of satire called 3 Simple Rules That Will Make You a 'Superstar' Developer that gave three simple rules and two deeper principles for becoming a hard-living, Type 2 rock star programmer.  It's remarkably concise and accurate.  But what struck me is how close the three rules and two principles are to rules and principles for becoming a real Professor on the Programming Drums.

"Prima Donna" Rule 1: Write lots of code.

Have to fix a small bug in an area someone else has written? Don't waste time trying to understand it or their motivations for writing it that way. Just rewrite the lot as you think it ought to work. Call it refactoring if anyone asks.

"Neil Peart" Rule 1: Read lots of code.

You will spend more of your career reading code than writing code. Learn how to do it well. That means doing it a lot.  Read code even when you don't absolutely have to, and understand it deeply even when you think a shallow once-over will tell you all you need to know. Have a spare half hour?  Read the last couple checkins from other people on the team, even if you don't need to. You will learn more about the system faster, you might find issues earlier, and you will probably learn something or see a technique you didn't know about.  Have a spare afternoon?  Find an open source project and start reading code. Copiously reading both awful code and good code will help hone your internal sense of the difference.

Prima Donna Rule 2: Write your code quickly.  

Touch lots of files, and include every one of them in the ChangeLog. Don't worry about accidentally introducing hard-to-find bugs; they'll actually help you later on, as long as they're actually hard to find. Avoid introducing trivial bugs.

Neil Peart Rule 2: Finish your code quickly.  

"Done" is a Boolean state, and work isn't done until you would be surprised to have to revisit it again in a few weeks.  Minimize your personal work-in-progress.

Don't let 90%-finished tasks rot outside source control in a local directory, because you will forget the details. Don't check something in, thinking "this will do for now; we'll get to hardening it later", because you *will* forget the details.  And it's not finished until it's tested to your team's standards, documented to your team's standards, and understood well enough that if you get hit by a bus on your way home tonight, someone else can take your place.

Prima Donna Rule 3: Don't take time to document your code.

And don't add little comments explaining potential pitfalls in modifying some of the less clear statements you've introduced. You don't need them--you wrote the code.

Neil Peart Rule 3: Document your code with a single-minded purpose.

Obvious code with only as much documentation as is needed is the Holy Grail. Undocumented and unclear code is as bad, but over-documented code can be worse because it becomes a crutch ("so what if the code is ugly: that's why I commented it!").

You already know that when you write code, you put your reputation on the line that it is correct.  But when you document code, you put your reputation on the line that not only is it correct and sufficient now, but it
will be correct and sufficient when someone looks at it down the road. So minimize your risk of shame. Boilerplate comments, rambling exposition, comments that duplicate the code, and commented-out code
left in "just in case" are signs of laziness hiding behind the mantra of "comments are good; more must be better!"

Behold, the Underlying Principles

Strikingly, each set of rules emerge from one technical principle and one social principle, and each set of principles is a mirror image of the other:

The Prima Donna Technical Principle: You're 10x as productive when you're working on code you wrote as on code you didn't write.  

So, maximize your opportunity to work in code that you wrote, no matter the consequences.

The Neil Peart Technical Principle: You're 10x as productive when you have full awareness and mastery of your environment.  

Yes, you can achieve that by always working on your own code. That will mean being so prolific that all the problems you're fixing are your own creations.

Or you can achieve it by having a deep and total understanding of as much of your team's project and tool set as possible.  And the cleaner a design or a development process is, the more of it you can fit in your head at once.

The Prima Donna Social PrincipleYou win The Game by improving your reputation to superstar guru levels.

Your programming ability is judged by how much code you write, how quickly you finish features and fix critical bugs and how often your insights are necessary to solve problems.

The Neil Peart Social Principle: Optimize your life for value, not perceived ability

Your value to your project and your team is only partially related to your programming ability (perceived or real).  It's directly proportional to your ability to add value to your project and your team.  The more deeply you understand your project, your team, your code, and your tools, the more value you can add.  Conversely, any technical debt you create will be repaid either by you or those who follow you, and servicing that debt reduces the mental "capital" you have available toadd value.

In many ways, the "prima donna" and "Neil Peart" principles differ only subtly.  Maybe that's why it's so easy to find yourself on one path, when you really think you're on the other.