Jeff Atwood points to an article on “How to Become a Rockstar Programmer” and also to Iron Monkey’s critique of said article that the #1 way to improve one’s programming skill is to study other good programs (“One Tip To Rule Them All”). Jeff counters in his own critique of that critique by asserting that a good programmer should simply write a lot of programs—that, in paraphrase, code quality is proportional to lines of code written. Another commenter chimes in with his two cents—learn the APIs well.
Rockstar Programmer
I decided to investigate the credentials of the original author—Mikael Grev. Apparently, he is, from his bio, the “president of MiG InfoCom AB, a company specializing in creating highly customized thick client applications and components for the Java platform.” He also writes a lot of articles on design patterns. Is he a rockstar? I don’t know, but his article focuses on becoming a code guru.
Iron Monkey is his aforementioned critique states:
Let’s start with the title. There is no such thing as a “Rock Star Programmer,” so if you want to become one, you already have problems that reading a blog post can’t fix. Rock stars get sex, drugs, parties, limousines, fame, glory, dates with supermodels, and >Rolling Stone covers. Good programmers get … uh … fewer compiler errors. Or fewer runtime errors, depending on which language you’re using. So let’s not pretend that “Rock Star Programmer” makes any more sense than “lighter-than-air paperweight” or “Rock Star Babysitter.”
I disagree that there is no such thing as a “Rock Star Programmer.” I do aspire to become one, and, for me, that means developing leading edge software that lots of people use and also commanding a seven-figure annuity in the process.
The assumption that the rock star programmer is also a guru is implied, probably erroneously, in the fact that he produces a compelling product that people buy over the competition and also earns a stratospheric income: If other developers were as good (or just less complacent and risk-adverse in their existing lifestyle), they should be able to achieve similar feats, modulo the very significant element of chance.
Some of the early EA developers were treated like rock stars, with hefty compensation and featured profiles in product advertisement. The developers of Doom, John Cormack and John Romero, were indeed rock-star figures with the income, girls and cars. John Carmack, for instance, appeared in TIME’s list of 50 most influential technologists, was inducted into the gaming industry Hall of Fame, was subject of the book Masters of Doom and even had a movie produced from his work.
Becoming a rock star usually involves both being an independent developer and developing a revolutionary new product. The first is required for securing the full property rights, being associated with the product, and capturing its full value to the marketplace. The second is less important, but makes it more likely that revenues from the product equals a rockstar’s sum.
A rockstar employee like Anders Hejlsberg, a Distinguish Engineer at Microsoft for being the father of .NET, was basically a rockstar before he began working at Borland and Microsoft. He hit it big as the independent developer of Turbo Pascal. When he was hired by Microsoft, he picked up a 200,000 salary (rather skimpy) according to a Borland lawsuit against Microsoft.
Trying to think of a counterexample, I first thought of Richard Brodie, author of Word and Bill Gates’s assistant, who seems to doing well, but then I realized he previously worked on the Bravo wordprocessor at Xerox Parc. What about Ray Ozzie, whom Bill Gates once called “the greatest developer in the world” and is now a CTO at Microsoft? His company, Iris Associates, developed Notes, which was later acquired by Lotus. I am sure there are legitimate counterexamples.
Becoming a Guru
The original article was more about becoming a guru than a rockstar. I have a few of my observations about what it may take to become one.
1. Being passionate about technology. Technology has to invade your dreams and be the cause of your distractions from other concerns in your life.
2. Attempt technically challenging (nearly impossible) projects. This forces you to quickly drop poor programming practices, and the end result is something (if it is finished) that impresses all.
3. Mentally travel. Living in other countries (not just simply touring) is a really good way to break down hard-core assumptions that you have about life. I have personally lived in China and the Carribean for a few months each.
- Read good articles and books that are likely to lift your coding abilities. I personally hang around CiteSeer and the ACM Digital Library to read advanced papers.
- Read a lot of good programs. To be able to develop commercial level applications, it’s helpful to see how existing applications have been written; there is plenty of open-source code available to study such as OpenOffice and FireFox.
- Develop a wide variety of applications.
- Learn to program in radically different languages. One of my first revelations was programming a Windows GUI application in Prolog.
- Gamasutra has a number of project postmortems, that allow one to vicariously acquire experiences.
4. Write and rewrite a lot of code. There’s no substitute for practice.
- Experiment with multiple data structures and algorithms. Be brave: develop new ones.
- It helpful to acquire a deep understanding of the implementations of the APIs and language.
- Also, know the hardware such as the memory hierarchy and the microbenchmarks. I can usually look at code and calculate within an order of magnitude how long a function call will take.
5. Realize the ultimate goal is less code. Less code is more expressive because it performs equivalent actions as verbose code; it typically is more intentional code. Data-driven programming, metaprogramming, code generation, declarative programming and DSLs are all means to reduce code.
6. Math is your friend.
