Archive for October, 2012

When I started writing this article I ran into a serious issue, defining exactly what a RockStar programmer is. The Term has the “God Problem”¹, a problem that atheists and physicists who dabble in philosophy face on near daily bases. Lawrence Krauss actually spend the better part of the preface in his book A Universe from Nothing: Why There Is Something Rather than Nothing explaining it. He practically throws his hands up in frustration stating you can’t prove that something can be created from nothing without the existence of God to someone who defines nothing as “That in which God creates from”. Being a somewhat religious individual I have decided to adopt that definition of “Nothing” (now a proper noun) because of its sheer strength in defending the necessity of God’s existence. But (hopefully) to prevent such arguments here, I will define Rock Star for the purpose of this article. Then if one wishes to argue if such a person exists or if it is a good idea to be such a person. It can be argued by means of saying “A Rock Star programmer as defined by Morons…”

So here is how I (Morons) define a Rock Star programmer: An individual who is a top level performer (let’s say more than one standard deviation). This person, when assigned work, regularly and consistently completes that work in a fraction of the time allotted without sacrificing quality, then spends the remaining time helping his teammates (by giving guidance, not by doing their work) complete their tasks on time, singlehandedly improving the performance of the whole team.
(The same definition can be used for Ninja or Jedi or the various other terms used to descried programmers of exceptional talent)

The reason I chose this definition is because I feel it is more in line with that a true exemplary developer is. The most common definition of a Rock Star is a programmer who is an order of magnitude (10x) more productive than the average programmer. I don’t believe such people exist but there are definitely people who are 5x more productive than the average. Even if you hold to this definition, the remainder of this article still applies.

(See: Are there studies clearly illustrating the great discrepancies in programmer productivity?)

Regardless of the definition, it’s becoming increasingly common in the programming community to say that Rock Star programmers don’t exist. These naysayers are absolutely wrong, these people do exist. But they only exist in an environment that allows them to exist. In such environments the average programmer is easily 2-4x more productive than in environments that are not conducive to productivity. If you don’t believe me, I ask you this: how much more productive are you working at home on your pet projects than when you are in the office doing salaried work?  There are entire books written on the subject of making environments conducive to productivity.

Employers love Rock Stars; they give their employer a tremendous value and have a positive effect on everyone around them. But that doesn’t mean it’s what’s best for you. What’s worse than being a Rock Star is striving to be one. Before you read the next sentence, if you haven’t already, you need to read my last blog article, if you don’t, the next sentence won’t make any sense… I’ll wait….Back? Good. The reason being a Rock Star is bad is because it is a lousy position to be in. The reason striving to be one is worse is because that means your entire career goals are wrong and you are striving to put yourself in a lousy position. Once you are in that position, your employer will do everything to keep you happy in that position, throwing money at you if necessary. But the day will come when you will want to move on, and that day will be a Terrible, Horrible, No Good, Very Bad Day.

As previously discussed the key to professional growth is learning new skills, putting them to use on the job, asking for more responsibilities and then for a promotion. The Rock Star doesn’t do this, the Rock Star spends years finely tuning his relatively small set of skills to the point of absolute perfection. This makes him less marketable, he can only sell himself on a very small skill set, and effectively selling himself as the absolute best to a potential employer is very hard ( if not impossible).

The Rock Star is highly valued by his employer and his job will be very secure, he will also (assuming he has some level of negotiating skills) be paid at a rate significantly higher than the industry average for his position. These two things actually work against him.  Once in this position, there is no opportunity for professional or serious financial growth.

Consider the following:

• The Rock Star can learn new skills, but can’t put them to use. His current employer doesn’t want him using his newbie skills; he wants him using his Rock Star Skills! That’s what he is being paid such a high rate for! But here is the kicker; the Rock Star is only being paid well relative to the market value for his skill set, but not relative to someone with a more valued skill set. Learned skills that have not been used on the job have very little market value. The Rock Star is stalled in terms of professional growth. The Rock star has been typecast and can’t change roles. If the Rock Star threatens to quit, his employer will let him go. If the Rock Star is not doing his Rock Star stuff, he is a regular expendable employee (who happens to be overpaid).


• If the Rock Star asks for a raise, his boss says “You are paid 25% more than any other dev on the team, your salary is on par with mine!, Sorry, no can do, maybe next year” The Rock Star has no negotiating position with his current employer; His current employer thinks to himself “Where is he going to go? No one is going to pay him as well as I do.” And his employer is right. The Rock Star is stalled in terms of financial growth.
  (See : http://blog.hirelite.com/what-developers-think-when-you-say-rock-star )


• If the Rock Star decides to look for a new Job, he will quickly realize his boss is right. There is no way to prove oneself is a Rock Star to a potential employer. There is no Rock Star Test. Nor is there a Rock Star market. He will be forced to accept a position as a mere Sr. Dev (a step down professionally) at less salary (a step down financially), hopefully this new position will offer him the opportunity to put some of his other skills to work and attain some professional growth which will then lead to financial growth.


• Even if he could attain another Rock Star role, at Rock Star pay, being a Rock Star is so dependent on the working environment of his new employer, there is a high chance of failure (to live up to expectation).


• If the Rock Start chooses to start his own business or go into consulting, he can, but he didn’t need to be a Rock Star to do this.


• How many years did it take to attain that Rock Star Skill level? Those years could have been put to better use learning new skills and moving up the corporate ladder.


• All of the above could be summed up with the following: The Rock Star is underemployed, but well paid for the job he is doing. The high pay mentally locks him into this underemployed status. His employer treats him well, is nice to him, gives him creative freedom, and a pleasant work environment. All of those things reduce his motivation to better himself, so he remains in that Rock Star position long term with little professional or financial growth. The longer he stays on this path the worse off he is.

Yes, I am actually saying it’s better to be underpaid than over, because you should have never gotten to the point where you are overpaid. You should have been promoted and taken the salary increase that comes with that promotion (so that your position is in line with your salary.) If you are overpaid you did something wrong, you should correct that mistake, in the interim take the money.

Lastly, I know that to many what I described above sounds like a dream job (an employer pays him well, treats him well, gives him creative freedom and a pleasant work environment). It is nice, but the fact of the matter is that those conditions weren’t created for the Rock Star, but are the only ones in which a Rock Star can exist. Those conditions where there when the Rock Star joined, and would likely still be there had he never become a Rock Star.

If you feel you are that skilled and want to reach your full potential with that skill, I urge you to reconsider. People who are that skilled should be running industries, not working in them.

Recommended Reading:
Peopleware: Productive Projects and Teams (Second Edition)
A Universe from Nothing: Why There Is Something Rather than Nothing
Alexander and the Terrible, Horrible, No Good, Very Bad Day

¹Any question where in trying to answer it results in an endless argument over definitions. All “God Problem” questions are off topic on P.SE as unconstructive.

One of the most persistent questions I see on Programmers.SE is “What language should I learn?” and its endless legion of variations. These questions seem innocuous enough; beginners looking for insight into the hideously complex and bewilderingly partisan world of software development. It’s more than just languages too. Languages all have attached cultures and ecosystems. Not to mention an endless parade of varying implementations and the other attendant issues like third party libraries and the melting, gibbering insanity that is the world of software licensing.

The problem isn’t that the question is invalid per se. It’s more that the motivations for asking it are typically suspect. People typically ask the question for one three reasons: They want to be magically employable by learning language X, they want to solve a problem automatically via language Y, or they want to expand their programming horizons but don’t have the research skills to do a proper job on Google. I’ll address these and several edge cases.

Speaking to Power – Languages that Employ:

The problem with “What language should I learn to get a job” is the nature of the market for languages. Companies are typically invested in a technology stack such as .Net on Windows or Ruby on Rails on Linux or something like that. You have the language, the development environment, the operating ecosystem, the deployment environment which may not be the same at all and numerous other considerations. Changing a development stack is non-trivial. It involves more than just installations. There’s training your team to deal with the code and/or the new elements of the refactored stack. There are business and legal considerations too like the cost of licensing. Individual use of a technology stack is often free. Company use tends to be much less so. Thus, companies tend to be more wary of the “new hotness” if they have a process and stack that generates money.

So you come to another case here, which is “I don’t like the stack I’m using and I want to change it without changing companies”. This is related to the second category I mentioned above about magic solving of problems, except that it is trying to magically solve your dislike of the tools you are given. Sometimes, this problem can be solved by using a cross-platform language like IronPython for .Net but often the support simply isn’t there for Language Z trying to make it into your company’s stack. Smashing the Stack is very real business concern if you’ve got a working process. Any disruption even if it’s just the injection of one new programming language can mean the difference between a profit and a loss. It’s natural to want the best tools but sometime the best tool is to adapt to the existing stack rather than wish for something “better”.

The root of this matter is the idea of the “silver bullet”. The problem is that programmers and engineers are trained to find optimal solutions. We naturally seek the best solution possible within constraints. The issue is what to do when those constraints are our own prejudices/desires? At that point it’s time to try and take a step back and see if what we are proposing is a realistic solution. The question to ask is:

“Are we fighting Werewolves?”

If you are fighting Werewolves, then using silver bullets makes total sense. Sometimes though you don’t have any silver. So the question is how to silver bullet without silver (or sometimes even bullets). The answer to be good enough at the fundamentals to hack together a solution. I know that aesthetics are important, technical debt is important but when it comes down to shipping a working product in an ugly language or 6 months late and beautiful; beautiful will leave you broke.

Putting Holes in Wizards – Magic Bullets for Personal Projects:

The same goes for people trying to get a language to silver bullets for a personal project. There is no one right answer. Everything is good for something. It depends more on a solid understanding of the problem domain of your project than a magic code from the beyond that swoops in save you the trouble of actually thinking. Sometimes languages make a world of difference but these tend to be domain specific like R for Statistics or a general language that has a particularly good setup for something like Perl’s Regex functions or Fortran’s numerical capabilities. Fundamentals are again key. Know what algorithms you need and how they fit into your problem. Solve the problem then figure out what language features you need to solve it most effectively. Then pick a language that does that optimally. Tada! “Magic” Bullet!

GoogleFu Programmer Style – How to Do Research in 2012:

If you plan on spending any amount of time doing any kind of research on the internet. Learn How to  Google. I’m dead serious about this but it particularly applies to programming where the situations are often very time sensitive. Language learning for personal growth is a great thing and usually not as time sensitive but it is no less imperative to learn to research effectively before asking around on the Stack Exchange, or anywhere else, but particularly on the Stack Exchange. Doing research often requires dialogs and discussions and that’s not something SE is particularly kind toward. Fundamental knowledge again helps here; it allows you to ask the right questions using the right words. Most languages now have websites and user groups. Once you get a targeted question, rather than a nebulous notion, it’s time to go ask it on the Stack Exchange. Examine the FAQs for your particular question category. If you are unsure ask on the site’s Meta. That’s what it’s there for.

Closing Arguments – Think before Asking and Never Panic

Language questions tend to Gorilla vs Shark more than most and I hope that this examination will help avoid that. Most of the time the answer is “whatever your boss/teacher told you to learn or why aren’t asking them this question?”. We are programmers and software engineers; Logicians, not Magicians.

The last piece of advice I’d give is to rubber duck your question: Read your question out loud at least twice to a nearby inanimate object. If you can’t explain what you’re trying to ask to the “rubber duck” you need to more carefully consider exactly what you are asking. Tight deadlines can be panic inducing but don’t fret. Take a deep breath and focus. Laziness is a virtue in programming in the sense that it makes you want to be efficient. Learn to efficiently research and communicate effectively with people and you will have a much easier time asking questions on the Stack Exchange, programming language learning related or not.