Wednesday, March 29, 2006

Top Ten Tips On How To Become A Rock Star Programmer (NOT)

Mikael Grev's JavaLobby article about the "Top Ten Tips on how to become a Rock Star Programmer" has gained quite some publicity lately. I first heard about it on the Java Posse podcast, and now Jeff Atwood posted a response on his weblog as well.

Like some other commentators so far I also tend to disagree with several of Mikael's statements, for example:

#2 Use a big TFT screen
I still have tube monitors both at work and at home, and my code looks pretty much the same as if I would be sitting in front of a TFT ;-) Besides, my email client at work will backfire on any attempt of running in dual screen mode (yes, it's Lotus Notes...)

#4 Don't learn APIs too well

Do you want people having to look up the documentation at each second line? I code most API-calls "blindfolded", I rarely consult the JDK or .NET Framework documentation. IntelliSense helps, but only as long as I type in component or method names which I am familiar with already. And I have met one or two guys who "didn't learn APIs too well". They implemented their own version of String.indexOf() - need to say more?

#7 Go back and enhance your old code
Now, my old code might not be pretty, but it works. I know what I would do differently today, but that knowledge stems from somewhere else. And if I know how to do it now, why bother and execute that change on an otherwise perfectly running system - it might break just for the beauty of a new approach. I'd rather apply what I have learned on current projects than on old ones.

#9 Don't ask people for advice
From personal experience, I have benefited most by working with and learning from great developers. I never hesitated to ask them for advice. And when in exchange someone requests help from me, I will be happy to assist. Mikael recommends googling instead. Google is great to look things up, but I wouldn't rely on it exclusively.

Summing up, my recommendations on how to become a Rock Star Programmer would go into a slightly different direction:

#1 Get substantiated education. It's not that everyone needs a PhD in computer science, but your local "how-to-become-a-web-developer-in-six-weeks"-course won't make you a real programmer either.

#2 Never stop learning. Read books and magazine articles, check developer weblogs and listen to technology podcasts, go to industry conferences, take each training opportunity your employer offers, etc.

#3 Work as a developer already during education, at least part-time. This allows you to combine theory and practice. Also, try to find a pet project you can pursue in sparetime, in an area apart from your daily field of work.

#4 Go sure you truly understand why things work the way they do (or why they don't). Don't second-guess. If this library operates fine in debug mode, but breaks in release mode, go and figure out where that flawed memory access happens.

#5 Observe how great developers are doing it. Look at their code and ask them when in doubt. And don't forget to transfer the knowledge you gained to the next one in line.

#6 Eat your own dog food (I agree with Mikael Grev on this one). Don't stay in an ivory tower designing stuff that might not be very useful to others.

#7 Use the best tools you can get, as this will prevent you from wasting your time on mundane tasks.

#8 Be self-critical. Seek perfection, but also be conscious you will never reach it. At the same time, stay humble - application programming isn't rocket science. Making mistakes is only human, just go sure you don't neglect the possibility that your code contains errors, and act accordingly.

#9 Be curious. Enquire what goes on under the hoods, decompile stuff you are interested in, have a look at the memory image in your debugger, use code analysis and profiling tools (like Purify, Boundschecker, OptimizeIt and Lint), or check at which rate your application opens and closes database connections, things like that.

#10 And finally: Have passion for your domain of work.