Catch me code

Fast Programmers

The legend has it that the best programmers are a magnitude better than the average one. Having worked with some that I’m suspecting (or at least hoping so the rest of us mortals have some chance left :) would be in the top echelon I’ve tried to draw wisdom from these people on what makes a really fast programmer.

Lets start with some rampant stereotyping into two categories!

The fast but sloppy

These are only seemingly fast. They tend to push work (although I think its unintentional) onto others thereby making them look fast. The speed comes from skipping on tests and edge cases. Some might even appear to be superhuman since they would be in the top bracket even if they would take the time to make their code high quality.

The thing is that the work they’re supposed to do winds up at other peoples desks in forms of bugs and hard-to-impossible to read code. So the amount of work you save on one guy is just moved (and multiplied by the amount of people) to another place. Unfortunately its very hard to track and prove. Bugs might not appear for months and unmaintainable code takes considerable time to surface and rear its ugly head.

These are not what I consider fast. These are only fast by omission.

The fast and precise

This is the recruiters pot of gold. The really fast but also precise and annoyingly almost always right. How do they do what they do?

This is purely from what I’ve seen myself watching these guys in action. I’ve tried to interview some that I would consider being in this category – but I’m guessing its a bit like asking Picasso how to paint: “Uh, dude .. just grab a brush and go” (In my head this is exactly how Picasso would reply :) – the replies didn’t reveal much. So with those replies I’ve gathered that its not something that’s intentionally being turned on or done on purpose. Its seems almost as a reflex.

Insane focus

This is the first and probably most important point. An absolutely unwavering focus. Everything but the problem at hand is secondary.

If you spend 5 minutes on youtube or twitter you know you’ve lost 5 + about 15 minutes (in context reset mode). Multiply this by the productivity of really good programmer and you’ve lost considerable distance already. By just zoning off for 5 minutes.

Not everyone can keep this focus as I’ve seen these guys do. I’m guessing its part built-in and part having the right tasks. But I do think that focus can be trained far more than what most have built-in.

This does not mean take no breaks. Do take breaks if you’re getting unfocused. We all have diffrent limits for how long we can keep at it. But here’s the kicker – take a break only after you’ve had a good productive run. Not before or during – because then there will be no productive run.

Iterate faster

Armed with the unwavering focus is a just as unwavering will to move forward. I mean move forward as in get your hands dirty. A wicked problem is a problem that cannot be solved until it has been solved. And I agree with the link – most software development problems are inherently wicked. You just have to try stuff until you find a way that works (note: not the right way – the fastest working way will do just fine).

This means not overengineering solutions or setting breakpoints on a bug right away wihtout speculating first. Get data and experience just enough solve the problem here and now. Tomorrow everything will change anyway – just go, start trying out solutions. The faster you can try it out – the faster you can discard it and move on to the next. And it has to be done in practice at the keyboard.

Produce more

This ties in with all of the above – the more you produce the better and faster you get at it. The fast programmers produces more code because they’ve already produced more code. The gap widens.

What to do with this?

Cultivate focus. Mediation is said to help. Try that. But first and foremost – try to get interested in what you do right now and ignore the rest of the world. Really sink into it. Use boredom to lead the way.

Try to get more interesting tasks. This way, having focus might not be so hard. If you’re a good programmer – chances are you’ll get to pick tasks and assigments earlier and earlier thusly getting the goodies first. So it spirals upwards – you keep focus and produce more because you get more interesting tasks.

Cultivate fearlessness and pragmatism. Try something. Didn’t work? Good, now you know. Now try something else (i e iterate faster – get more experience on the problem, the domain and your tools).

Don’t confuse sloppiness with being fast. This is the dark side of the force. Don’t go there… it will catch up with you.

As said, this seems to be built-in for most of the fast programmers I’ve talked to. But that does not mean you should stop trying to emulate that – au contraire! If practiced enough it might become second nature to you too..

And all of this is summarized in the words of my imaginary Picasso: “Uh, dude.. just grab the keyboard and go”.

Comments