Scott Hanselman

Excellent post, Scott!

Thinking of better ways to manage technical teams is a passion. I think it requires passion. I love your comment about never being the smartest person in the room. That's been my experience, too. It's not about being smart; it's about pulling together towards the same goal.

:{>

Great posting, and encouraging to me as a Software Engineering student preparing for graduate study. As the Vice Chair of ACM, I keep trying to tell our members that just cause you passed the class does not mean you know subtleties, and that you also don't know how to be a good teammate and asset to a company on coding skills alone, but that your ability to communicate with others is SO important.

Great stuff. Thanks Scott!

While the distribution of skills can be normal (by the way, do you have any evidence?), the distribution of results is anything but normal. You can lock 20 math teachers in a room for a year, and they still are not going to solve a problem similar to the one that Grigory Perelman solved. Yes, mid-level developers can finish a mid-level project, but sometimes there are challenges that are beyond what they can understand, let alone overcome.

Great post, Scott.

It's the same idea that gathering up really talented people together means you'll have an all star team that wins every time - another myth. While a group of talented people will surely produce better stuff faster than a group of people who suck, the real thing that makes them succeed is a team that works well together. They'll play off each others strengths, compensate each other's weaknesses and encourage each other to grow.

After my first decade in the biz I'm now doing the management thing while trying to keep my hands in the code. One thing I'm learning very quickly is soft skills can be far more important than technical, and like you said passion to solve problems mean everything.

My management strategy in a nutshell is very simple: Find people, encourage them to build themselves up, keep their passion alive and make it fun to solve problems. I am a work in progress, but I know that's the real key to getting stuff done.

The purpose of the rockstar isn't to make problems disappear, its to take all the resources available and create a better, simpler solution than anyone else has, and then motivate your team to follow that lead. The same rockstar doesn't do it alone, but they have the vision,talent and motivational skills to achieve what most can't.

Great Post.

I just shared this with several of the leaders on a project I was associated with last year. On that project they had an award that went to the "sprint mvp" and I spent the entire time cringing. Had I been able to say something as well as this post says it I might have been able to have more of an impact on the project.

I like your "word math." In a sense, you and Jon Galloway are offering simple formula for "doing better." And that's what you need in the heat of the moment.

I often feel like George in that Seinfeld episode where he can't think of the rebuttal zinger until he's left the meeting. I'll read posts like this one and watch videos like your "magic unicorns" video from a couple of years ago multiple times until the solutions are burned into my brain.

I wish I would have had this one last year. Thanks, Scott

Hi scott,
Great article. It reminded me of a presentation by Dan North at ndcoslo 2013. No one is a rockstar, but you can make a team that rocks if you put the right people together. Take a look at the presentation here https://vimeo.com/68226771

Best regards
Rasmus

The difference in productivity between a great and a mediocre programmer depends on the task. For mundane/trivial/repetitive tasks both are probably about equal. For highly skilled work the great programmer can easily be more than 10x faster. Part of this is that his solutions are more solid and require less ongoing maintenance/fixing/babysitting.

tobi is right. But managers sometimes fail to recognize "required quality" and push "speed only" putting up a fast mediocre programmer in front of a skilled one that actually takes more care in completing the task, ensuring future maintenance and extension cost to be low.

The idea of a rockstar programmer is a myth, but that doesn't mean you can't get programmers who are 10x more productive than others.

If you read through Peopleware (DeMarco and Lister) they ran studies many moons ago looking at programmer productivity and they found the oft posited 10x difference. When they looked into it, they found that individual factors made little difference (experience, salary, programming language, defects); instead, it appeared to be significantly related to environmental factors rather than individuals.

...which is why I facepalm whenever someone says the studies talked about in Peopleware aren't valid because it wasn't a controlled environment... /facepalm.

There's a summary of the relevant chapter at http://javatroopers.com/Peopleware.html#Chapter_8

What gets me is the org I work for are moving into a new office space in a few months, and we have been promised a world class working environment to help attract the best talent etc etc, and from what I've heard, the layout of the office is more or less fixed and we seem to have made all the wrong choices regarding developer productivity.

"Step aside" from nonprogrammers is the biggest help you can get from them. Also, finding the right people fro your team can be very hard...

IMHO the term 'rockstar programmer' is introduced to describe a programmer who is part of 'the best', the elite. So in my view, the term itself is not something that's wrong: the way it is used is off, and I agree with Scott that one shouldn't use it to get the best results (i.e do not focus on an individual, but focus on building a team to get the best results). I don't agree with the 'myth' part.

'The best' is a vague term, many people think person X is part of that group, or they even think themselves are part of that group, based on their own definition of 'the best'. As we as an industry can't even agree on how 'great code and design' looks like, we certainly can't agree on a set of criteria what 'the best' means and thus who should be allowed to wear the leather jacket with the 'Rockstar Programmers' crew banners on the back.

It all depends on the criteria used to define 'the best': with any set of criteria, a given subset of the group of programmers will fall into the group 'the best' and can be named 'rockstars'. That doesn't make them a myth, they're real (some people are better at creating software than others). The real myth is that by having a rockstar in a team, the team will function better and will get better results: it's not a given that by adding a person to the team who is so good in her/his job, the team will achieve more than when that same person wasn't part of the team.

But saying they're myths means there's no possibility for a programmer to be part of 'the elite' or 'the best' (for whatever set of criteria you're using), which is odd, there is always a group of people which you can label 'the best'.

A common misconception about the "10x engineer" meme is that it is about engineers that are 10x more productive than an average engineer. It isn't. It's about the fact that there is a 10x span in productivity between top and bottom, and this is mostly due to the low priductivity people. In a company with one 1/10x engineer *all* the others are 10x engineers, even though they may be average, not rock stars. And bad developers certainly arent unicorns. As for the real rock stars, we have all seen them. They enter stages to rock music at conferences, and have job titles with "evangelist" in them. Seeing those guys motivates me, just like seeing a concert motivated me to learn to play the guitar. I'd say Scott himself is a rock star programmer by this very definition. I agree it's probably counter productive within an organization to point at a few rock stars, but for the industry as a whole guys like John Carmack are an inspiration.

I have to disagree on this one Scott. We have a "rockstar" developer on my current team. He truly is amazing in every aspect of his life. In fact we even have a saying in our satellite office: "You'll never be better than DH." He not only clears the most work items, but he has adopted foreign children with disabilities, which I imagine is a great challenge and altruistic. I changed his name to his name to initials to protect his privacy, but your blog doesn't truly apply to him. Once we had a team building exercise in San Francisco near my employer's HQ; we were just hanging out. Our "rockstar" developer almost stepped out in the street as a car ran a light. Our Senior PM said "if you take him, you might as well take me too." Obviously he was implying that our project could not survive without our "rockstar" developer.

That isn't completely true. I joined the project and have had to modify his code. He is nowhere near perfect, but he does the best damn job he can with the information provided. Hindsight is always 20/20, so it is easy for me to identify flaws in his code as I make changes as a fellow senior developer, but the fact still remains. He is damned good at choosing patterns that keep his code maintainable. He is also excellent at helping when you don't understand why he implemented the code the way he did. When you get his explanation, he has a great reason for it based on the requirements at the time. Seriously, our "rockstar" is just damned good. When the next rev of C# comes out, he has researched it and become an expert, but you'll never see him on Twitter or Facebook. He is one of those "dark matter developers."

Scott,
That would be great if you were introducing your evidences to make your opinion more reliable

I see you found Shanley's blog. I would add an older one from Joel.

I have to disagree with this one Scott. Starting in college we were taking a class with a debugging lab two of us completed it in <20 mins, the other 6 took >3 hours allotted to the lab, even with the help of the other two the entire time.

On a separate occasion, I gave two developers an entire two week sprint to do a single (easy task), on the last day of the sprint they said they couldn't do it before the end of the sprint. One developer (not me) took on the task and had it done (well) in less than 3 hours.

It doesn't matter how many anecdotes are chosen either way. I have seen developers work at 10x speeds compared to their brethren. Whether some are particularly good or others are particularly bad doesn't really matter to me. What matters is that there are some people I want on my team and others that I do not.

It doesn't matter how well you communicate if you can't code your way out of a paper bag. At the same time it doesn't matter how well you code if you can't communicate to your team why and how you did what you did. We really need to stop pretending that you don't need to have both skills, and to a high degree, when we talk about programming as a profession. You need to be able to both code and communicate, having one or the other just doesn't cut it anymore, if it ever did.

I know one rockstar programmer - Ayende.

Hi Scott,

I totally agree on this. Also the post of Shanley is a great read!

The Management 3.0 training of Jurgen Appelo also touches this in the training. How to grow as a team and that one uber dude won't help you deliver-faster-better-software.
Especially in the Agile/Lean way of work it is important to put the right people next to each other and help them grow as a team

The image at the top of this post rocks "There is an I in Team..."

Thanks for the inspiration.

Piotr Perak, in what way are you referring to Ayende as a "rockstar programmer"?

Do you mean in the good way, as somebody who quietly creates a huge amount of extremely useful code very quickly? I'm thinking about "rockstars" like Guido van Rossum and D. Richard Hipp as people in this category.

Or do you mean in the bad way, as somebody who is loud and outspoken, writing lots of blog articles, acting as a know-it-all? In this category I put most of the prominent "rockstar" Rubyists.

I do not know which one you mean, but I suspect that you may be referring to the second definition. While I have read many of his articles, and never found them particularly insightful, I am also not aware of any important code that he's written that I've also used frequently.

Some complex problems require complex solutions.
An optimized algorithm is typically more complex than a naive one, but nevertheless required many times.

A senior developer knows when a complex solution is required, and can deliver it avoiding unnecessary complications.

Also,
There's no bottom to how worse a programmer can be.
There're certainly programmers who are 10x better than others.

How about saying that if we use the label "Rockstar Programmer" for the statistical outliers, we are either telling lies, or telling harmful truths. Insisting that it must be a myth creates a reason for discarding your most important point. So don't give people that option.

Some readers may take exception to the idea that "there are no Rockstar Programmers", since that sounds like youare denying that outliers exist, even though you clearly state that you do see that they exist. So outliers exist. So some developers get more done than others. Saying that even the outliers will ALWAYS get 10x more done than the middle-of-the-curve developers is rediculous. Gaussian distribution is probably reasonable. So there are probably 2% of developers who get UP TO 2X more work done per year. Of course measuring amounts of work in any comparable way is also B.S. So I'm not willing to even agree that any developer can get X times "more" done, because I don't see the work we do as being reducible to any meaningful Unit of Work. The work developers, good, bad, or otherwise do, is too complex to be reduced to a single axis on a graph.

I think we can agree that the idea of calling them out is harmful. The idea of telling everybody else that they don't get the same level of Privelege as the "Rockstar" does, even on his or her bad days, is a disaster.

I got told by the person who thought he was a rockstar that the main thing wrong with my code was that I didn't quite follow the prescribed in-house whitespace style. (A style that was not even mutually consistent, within its own description). How many hours do we waste when we tell everybody to follow the leader, even when the leader is wrong? A lot more hours, when Rockstar Status, or any other form of Privilege replaces reason. Architect titles, Chief Scientist titles, are the same kind of bullshit, and Microsoft is one of the chief offenders in that area. Changing the name Rockstar to some other corporate B.S. title is the same thing. Google is remarkably free of this form of stupidity, it seems. I don't know about Apple, but I suspect that Steve Jobs was the very Platonic Ideal of the ideal of the victory of Position, Privilege and the Jealous Guarding of Power over the practice of pure Reason.


Warren

Shanley's article reveals the error more clearly. Shanley quotes:

"In short the $20,000/year programmer may well be 10 times as productive as the $10,000/year one."

Well, no, that doesn't sound right at all. But a $100,000 a year programmer probably is 10x better than $10,000 a year programmer. At any high-end tech company you're probably not going to be hiring too many $10,000 a year programmers. Let's say you have $65,000 at the low end and $200,000 at the high end. Are the rockstars who make $200k really three times as productive as the junior who makes $65k? Yea, probably. Would a $20k programmer really be 10 times worse than the $200k rockstar? Yea, probably, but you're not likely to be hiring $20k programmers in the first place for **EXACTLY THIS REASON**.

Of course, depending on the project, a $200k programmer might not do the job better than two $100k ones. Diversity of minds is important, especially when the scope is too large for one person to keep all the minutiae in their head at once. Thus: the scope of the project is what determines team size. Your budget is no doubt pre-determined as well. Given a desired team size and a budget, you would then hire programmers accordingly. I suspect this is close to how hiring actually works in the actual real world (at least for productive companies.)

Does calling out the "rockstar" demotivate the rest of the team? Possibly, in some instances. (Certainly if they receive unwarranted recognition.) But isn't it just as likely that some team members will look them as someone they want to emulate?

It seems to me that this would depend a lot on *how* it is done. Occasionally making note of individual achievement isn't a bad thing. Occasionally noticing team achievement is also valuable.

People who are easily demotivated when someone else gets rightfully recognized for their achievements aren't good team members anyway. People who are excited to work with smart talented people have the right attitude. People who are automatically jealous when other people get recognized are bad team members.

And anyone who has worked with a truly bad developer knows that there is a huge range of skills out there. Is it really 5x or 7x or 10x? I dunno. But even 2x is a huge difference. And there is a difference.

Great post, Mr. Hanselman!

I've seen and worked with self-proclaimed Rockstar programmers a few times. I've also seen how some team-members really get demotivated.

It's good to see a more recognized developer talking about this.

There is recent research on the topic that seems to indicate that these efficiency differences are present and measurable in software development teams. I agree that terms such as "Rockstar" doesn't really help us understand how and why, but I find the research from for example Magne Jørgensen and Stein Grimstad from the Simula Research Group interessting. Here is their presentation from NDC Oslo 2013 https://vimeo.com/68331761

Mr. Hanselman. You are totally wrong. I've been in software development for over 20 years and I've seen many projects make it or break it by "rockstar" programmers. No process can improve on a team of rockstars and no process can make a team of poor programmers better. The poor results of eXtreme Programming over the last 10+ years has shown how a process designed to reign in "rockstar" programmers and level the playing field produces a lower quality product that almost always exceeds budget and schedule.

This has been my experience as well:

• Junior Engineer - Creates complex solutions to simple problems.


• Engineer - Creates simple solutions to simple problems.


• Senior Engineer - Creates simple solutions to complex problems.


• Rockstar Engineer - Makes complex problems disappear.

Yet, the reality is most teams have a mix of all of this. At least with my experience on teams in Minnesota. I would even go a step further to say, that once you meet a developer who is happy at the level they are at they typically don't do extra work to move on to the next step.

That's where I feel issues occur on the team. It's when a team member is not motivated to do the right thing, or they are fine being an Engineer and nothing more. It's when this happens that I have found projects typically fail.

So that's usually the elephant in the room, and I make it my goal to try to focus on fixing that situation.

I think this post is true, but in the context that the team already consists of "good" developers. I know defining good is difficult, but there is a HUGE difference in productivity and quality between developers that care, and those that don't. In my experience, the senior developer that hasn't bothered to maintain proficiency in their craft is not as useful as the junior with far less experience, but has a passion for learning (or at least isn't jaded enough to have lost their passion yet).

In short, I think what Scott says is true when the team already consists of people who *want* to be developers, and *want* to be good at what they do. But anyone who's ever worked on a team with a developer that only became one because they wanted the paycheck knows full well that comparing that individual to the rest of the team is comparing apples and oranges.

@Flenderson
He is both loud and create a lot of usefull code :) - Castle Windsor, NHibernate or RavenDB.

Perfect troll post, getting popcorn for the comments.

In a world where many programmers can't complete fizzbuzz I don't think it's so much that the 10x'ers are really elite, it's just that the majority of programmers aren't very good.

This is a very young field. The training in the vast majority colleges does not prepare you for the workforce at all. People waste years of their career writing poor code. If they are lucky they get in with some people who show them things like separation of concerns, TDD, etc.

I was a hiring manager in my previous life. I had a test similar to FizzBuzz and can confirm a > 75% failure rate with visual studio, MSDN, and an open internet connection. I look forward to the day when the training for software developers gets better and when certifications actually are given in a format that is meaningful.

Piotr Perak, those are the kind of softwares that I would say are not useful. They are like Ruby on Rails; they are good for hype generation but they cause problems for developers and end users who have to actually use them.

Dependency injection is a bad thing in practice. It makes for softwares that are very complex and extremely difficult to debug. Any framework that enables this, including Castle Windsor, is harmful in my opinion.

The same goes for NHibernate. My Good Lord, you would not believe the disasters I have had to fix up due to people using NHibernate! In my findings, NHibernate is one of the quickest ways to slow down a database to a complete crawl due to the very worst of queries being generated. The expertise it takes to use NHibernate effectively is much harder to acquire and use than that needed to write SQL queries and data retrieval code by hand!

Don't even get me started on NoSQL databases! My Good Lord! Not having a schema is only for the lazy. Not having a proper query language is only for the ignorant. Anything we can do with a document database can be done better with a relational database. Document databases and NoSQL databases have no reasons to exist for almost all use cases.

I cringe and sometimes I even cry tears of pain when I am the victim of systems that are users of such softwares. I weep and I weep, for I know that I will be in a world of suffering, and the users will be, too. I weep for our collective pains.

I disagree that this is a myth.

Years before I heard anything about "10x", I studied the capabilities of all of us CS students (attending a CS school that was not at the top, but certainly not at the bottom either). I estimated that the best students were 6-8 times more productive than the "midrange" (where the vast majority of students clustered).

In the real world, I found a similar discrepancy. Some companies have gotten really good at keeping the top talent and showing the others the door - so of course there's not a huge discrepancy in that company. But the discrepancy in skill is certainly there. Just because some companies (e.g., MS/Google) have better than average devs doesn't mean that all devs are that good.

I've never seen a "10x", but 6x-8x is certainly realistic.

"Rockstar" is such a stupid word for this. Usually, it means "good programmer". At times it means "as good a programmer as I can imagine" and is used by people who think they're the bee's knees and want people just as unimaginably, unreasonably bright as themselves. (Run.)

Sometimes it really means "remarkably excellent programmer". Most of the time, it means a pretty good programmer stuck in an environment without other good programmers, or where they don't want to touch the pretty good programmer's code because they're afraid of messing it up. This is poison to the team and to the end result, but it's poison on a time delay because you'll only ever know once the pretty good programmer leaves.

I'm not saying everyone should regularly get into everyone else's code, but the codebase should be so good throughout that the problem of touching an arbitrary part boils down to what you know about the purpose of that part - not about the peculiarities of how it's implemented.

Some lines of code are more involved than others, some require hacks or maybe even inline assembly. They can usually, although not always, be categorized into two buckets: we're doing it in this complicated way because we had to due to some constraint of language or backward compatibility or what have you; or we're doing it this arcane way because of performance and optimization. No two of those are things you want to add more to for the good of the project or for the ease of maintainability for everyone. Let's say you do know how to work all this code - it'll still take you more time.

So if everyone should be able to code everything (no, not really, but let's go with that), why would you need these "rockstar" programmers? You wouldn't, but you want as many as good programmers as you can get for the obvious reason: they solve problems easier, which means they can solve more easy problems, they can solve hard problems better and they may even be able to solve "impossible" problems.

As for capacity, Joel Spolsky is right when he says that "the Garfield guy would never in ten lifetimes produce the Sistine chapel" or however he put it. Clearly some people are remarkably good. But most of those people also know to put their own thoughts into clear words. Any musician can play the scores Bach wrote. The real geniuses don't have to prove their advanced intelligence by hodgepodge that only they can understand; they are geniuses because they can solve an advanced problem by putting the solution in simple terms - or at least simpler.

But as Scott says, none of this matters so much as more people being able to get a handle on what's going on, or to solve a problem together rather than hoping the anointed office genius solves it lest they are doomed. Even if you are the anointed office genius, I don't mind anyone citing job security these days, but it's in your best interest to get someone else who knows what they're doing aboard, because you'll also be better and you'll be able to take a vacation or get sick at the wrong time without the world imploding.

@Flenderson: Progress always means introducing new things that have the potential to be abused. That does not absolve anyone of misusing anything or mean every new idea is equally useful. Your paragraph on NoSQL databases in particular makes it seem like you're seeing them as half a car rather than all of a motorcycle.

There are use cases for both Redis-style databases (with distributed operations happening on data structures) and document databases - go ask anyone who uses them and they'll have a list of reasons why relational databases would be more tortured by their use case than a particular other database. In some cases, it's even the case that SQL databases form the backing for the other database - much like people would argue that "SQL databases is faster than files", despite SQL databases clearly storing data on disk as files.

That said, of course you could be in a project which has brutally misused the wrong technology. That's not usually the fault of the particular technology, it's the fault of the particular decisions made by the particular people. By all means hate the hype if you want, but hype alone doesn't get it into your project.

Reality is a normal distribution curve. Lots of good average senior developers, some amazing outliers and some junior folks with potential. (and some folks that suck.)

Maybe that is the normal distribution curve at Microsoft, but not for the industry as a whole. I'm assuming you've interviewed people before, or you are at least aware of the number of people MS hires versus the number of people they interview. If what you are saying is true, then MOST of the people you interview would be hires, since you have "lots of good average people." In my experience the "average" developer SUCKS. The average developer that YOU work with doesn't suck, because, well, MS is discriminating in who it hires. Many other companies are too, but I've interviewed MANY people over the years where I am *shocked* that they actually have a job programming; *that's* the average programmer: the one who *can't* solve fizz-buzz; the one who supposedly has years of experience working with SQL, but can't tell you what a HAVING clause is; or what a hashtable is; or what SQL injection is, etc. So, IMO, your "average good senior developer" is absolutely 10x more productive than the *actual* average developer. You are right that a rockstar developer is not 10x more productive than GOOD developers. But boy oh boy are "good" developers not average. I wish they were, it would make all of our lives a lot better :)

Justin.. the quote about the $10,000 and $20,000 salaried programmers is from 1975. I was only two years old then, so I'm not sure what salaries were like, but we have had nearly 40 years of inflation since then. :-)

The point he was trying to make is that paying twice as much could get you a lot more than twice the results. Look at the ratio not the historical numbers.

I do not know whether I agree with your position or not. The challenge for me is truly defining what it means to be a rockstar or rockstar developer; and doing it without splitting atoms.

I think I *was once* a rockstar programmer. I was (a) more productive than my peers (b) understood and solved complex problems (c) intimate knowledge of every part of the stack from the CPU, CPU cache, memory and disk systems, all manner of device drivers, complete knowledge of the OSI stack, and the internals of DOS, OS/2, Windows and AIX; as well as realtime systems. Later when I started developing transaction systems for business I had managers who treated me like a rockstar and they allowed me to behave like one. (releasing my inner a-hole).

I'm reformed now. Many of my peers type faster than me and there are many more of them. Most complex problems are no longer complex thanks to a lot of open source and the internet. Since I no longer work on projects that have that sort of demand I have allowed a lot of that information to flush my cache. It's nice to refresh from time to time but not required to do my job.

And finally, my managers are more sensible now. The industry as a whole has changed. Would-be rockstars are being "handled" (McConnell says fire them; "debugging the development process") and processes like agile try to alter the set-point.

I still enjoy the work, the challenge, the stress, and the "problems". But I no longer want to be a rockstar. Just show me the money instead.

Completely disagree with this posting. It has got to be one of the most idiotic things I've come across. Not only do you rebut your -own thesis- (after saying rockstar programmers are myth, you then define what a rockstar programmer is), you also use completely asinine justifications: because other people feel 'left out'? Poor you.

It is utter ignorance to believe that best-of-breed, "rock star" programmers don't exist, or that, at least, top-caliber programmers are not capable of doing the work (or undoing the mistakes) of a dozen average joes. The question isn't whether 10 rock stars can produce more code -- indeed, they generally produce less -- but whether they increase the company's bottom line, ability to scale, grow, and adapt.

In fact, the reason a rock star can replace the work of 10 others isn't because he's necessary doing 10x that work, but rather because (i) he's avoiding have to undo the bad work of others; (ii) he's not losing time entering into 'team dialogues' for the sake of the team, wasting precious resources of a game of dick wagging/respect building; and (iii) by having fewer people, he's able to push forward an ambitious agenda without team road blocks.

Teams are overrated generally because 'team' often means 'come to consensus' when many of the people on the team don't know what the fuck they're talking about.

In general, the amount of pure mediocrity, laziness, lack of problem solving abilities, and just plain incompetence among programmers is astounding. Especially when it comes to 'getting things done.'

If I sound biased it's because I've seen the effect of working with small, high-impact teams of "rock star" engineers in the most intense, bottom-line environment there is: finance front office. Give me one top-notch guy who knows the business, knows how to get things done for the business, delivers results nimbly, and doesn't get caught up in nonsense bureaucracy and old school technical nitpicking and I'll show you 100 IT folks who do little but get in the way.

Of course there are !!

And not just in programming but also in pretty much everything. This is not to say that everyone who is not a rockstar is somehow bad, it is simply to acknowledge that some people are more gifted and more driven then everyone else. The old 80/20 applies: 80% of the work often gets done by 20% of the people.

Actually, since you are referring to the normal curve, aren't you already saying that rockstars exist ? Most people fall in the centre and are OK, some are truly bad - but at the other extreme some are truly amazing.

The trouble begins when an average person gets a lucky break and starts considering himself a rockstar. Hence the rule of thumb: Rockstars never refer to themselves as rockstars - others decide this after seeing what they are capable of. True rockstars are humble and ordinary, they have too much confidence in their work to want to somehow flaunt it.

Divas are a problem, sure, as they have attitude-without-ability. Rockstars in my books have ability-without-attitude.

I have to agree with Eric - the issue is that there are a great majority of really bad programmers. I am in Johannesburg, South Africa, and while I can't comment on the quality of programmers elsewhere, over here it is so bad, they have had to dumb down the interview process, including programming assessments, because the great majority of programmers fail them hopelessly. (Of course this fixes the symptom, not the cause.)

Really nice post.

Once upon a time, I was a Rockstar programmer but then I made a mistake of getting married.

For someone to be a true 'rockstar' developer I would expect them to be able to do the following:

Come up with elegant but simple to understand solutions

Write code that is easily maintained by any team members

Be able to communicate their ideas clearly to the team

Is involved in the community in some way, either doing talks, answering questions on StackOverflow etc

The communication really is key. It doesn't matter if someone is fast or efficient if everyone else has to pick up their mess afterwards. Teams need to work together to solve complex problems, and the skills need to be passed on to the rest of the time. Software development isn't really the place for lone heroes, unless you are working on your own project or start-up.

Take a deep breath & stop being jealous you've never been called a rockstar ;-)
Seriously though, why get worked up about this rubbish? It seems only American companies (gross generalisation, not intended to start a riot) are so focused on who can be the shiniest, newest toy. Guess what, the rest of the world, we've got real problems and they don't include building development cultures that advocate poor team work because everyone wants to be an individual. Just learn to get on with it.

completely disagree.

Interesting and insightful article. A different angle was given by Jeffrey Snover about Hero Programmers : http://www.jsnover.com/blog/2012/03/18/on-heroes/

Before I left my job in IT for a more creative life I was a rock star programmer.

I can agree that RS programmers will not perform well if they are left with mundane tasks. It bores us. However put someone like me in a team with good general developers you will boost productivity all round. As long as the RS is not a diva and enjoys teaching people how to think the team will preform brilliantly.

It frustrates me when people use the idea that there are no fantastic people in any field as an excuse for not excelling themselves.

I remember some 'Rockstar' developers. People who could build out entire applications in a couple weeks. Here's what I've personally noticed about these people. First, they are isolationists, they work alone, thus their work is a mystery to others and because of such is usually maintainable only by the 'rockstar.' Secondly, they usually have no ability to mentor others, they cannot teach their 'rockstarness' to others, somehow this ability cannot be transferred. They ususally have poor social skills which stifles any collaborative work.
In my not so humble opinion I believe these developers bring a lot to the table and also leave a lot out. If you're looking for someone to crank out miracles then you may be able to find one of these 'rockstars.' But if you're looking for people who will share their knowledge, grow a team, work on something collaboratively then these kind of people are not the ones you need.
I think the world needs both kinds of developers, 'rockstars' who can crank out really good apps fast and collaborative mentors who can build solid teams with a core of knowledge and encourage self confidence across the board.

Generally, the better a developer is the more he ameliorates likely problems. For example, a bad developer thinks "This code will never be used anywhere else, so I'll hard-code everything to get the work done more quickly," but a better developer realizes that thinking of this sort often leads to more work in the long-term, so generalizes his code to a greater degree than the bad developer does. Much of the distinction between topnotch developers and bad ones boils down to the aforementioned difference in thinking.

Very interesting post,

Most of the diva programmers that I have meet, are good programmers only because they have been working on the same project for many years so they know the project's code very well, once they are out of their comfort zone, they are just average programmers, in my opinion, a good developer is made not only for the years of experience but also for the diversity of the languages, platforms and projects that they have worked on.

My two cents.

I generally think companies who posts "rockstar" anything is a joke. They are unrealistic and have no idea what they even think they want, not to mention actually need.

Oh how I hate the usage of the word 'team', and all the other trite expressions that go along with the justification of the concept.

The 'expert' programmer has stuck around long enough to understand what the system does. He knows the tools and their limitations. This is how the job gets done on time, and works as expected.

The team? Well they read whatever spec there is, without knowing the business, and then decide what 'technologies' to use (you gotta use atleast 6 - 8 languages - right?). And schedule many, many, meetings and reviews. Add to that the silly automated QC testing, that really doesn't test much at all.

This is what programming has turned into. No fun. Just a predictable office job, with a medicore wage. Dilbert is soo right.

I'm an older programmer. I was so lucky to begin my programming career in 1969. Made very good money, and didn't have to put up with this kind of middle management malarkey.

Ask yourself: "If I'm sucessful, why am I wasting my time reading / posting opinions on a forum like this? When I could be using my time to make more money". The answer is: hiddenly, you're frustraed by this entire mess that is now called software development.

I am glad I read all the comments before responding. I pretty much agree with what Adam wrote above. As a former "rockstar", albeit in a small company environment, I never felt like I had talents above everybody else so much as the vast majority of the programmers I worked with just didn't get it. I mean, at all. I went to college for a year and a half, mainly just so I could be around computers in the days when you didn't have one in your pocket and 11 more in your house. I completed the course work for my programming classes the first week of the quarter and spent the rest of the time in the computer center doing whatever I wanted and not studying for my non-computer classes.

I don't remember exactly when I gave up on being a rockstar. I was self employed for a long time, after 15 years of basically keeping other people's promises and fixing other people's code, I went on my own and made my own promises and only had to work on my own code. It was a good run. I got a job offer too good to refuse, and as someone said - it's about the money. I'm still in a very small company environment, don't have to deal with teams or the "consensus of know-nothings" to impede my progress, and I'm virtually anonymous. I've gone from rockstar to the house drummer, but making 3x the money and no paparazzi. LOL.

Programming has been good to me. It's a gift, and was kind of an unexpected one. I discovered I could do it - and I got it - while still in high school, at a time when programmer wasn't even on the radar as a hot career choice. I couldn't even explain to my family members what I actually did for a living. But I don't love it like I used to, and I don't take it home. I have half a dozen other hobbies (including music - actual music) and programming isn't one of them. I don't get excited about new software releases. Even my iphone is 2 generations outdated, and I'd be distraught if I accidentally said yes to an update.. I wish it would just shut up and stop asking.

Oh yeah, a followup... one of the crippling things about being a rockstar back in the 70s and 80s, is managers would look at you and think if they made you a manager and gave you a staff of 10 programmers, then you could crank out 11x as much work. As Chris Hayes put it, it's pretty difficult to teach rockstarness to others. I found having people working under me to be a hindrance - a babysitting job that caused nothing but friction between me and my "staff", and productivity ground to a halt. I was caught in the middle, my entire job consisted of being middleman and there was simply no time to use my actual skills to do my actual work. I had to go through several cycles of this before I learned for sure it wasn't going to work, and then more to convince my bosses that no, you can't go hire out 5 contractors to speed up a project with me "managing" them. If you want my project done on schedule, shut up and leave me alone... I still have to fight that one on a regular basis, even after working with the same management for decades. They always have to try it one more time.

@Winston: Exactly my experience - teams of know-nothings - giving themselves a group excuse - where nobody is responsible for anything.

Success is about having options, money buys options. Not titles, not awards, not the recognition is in the paycheck.

I have two degress - don't get me started on this phoney 'certification' stuff.

Personally I've always hated the term "rockstar" applied to developers because of the stereotypical image it invokes - talented, brilliant, yet arrogant and prone to tantrums/room trashing.

I much prefer striving to be a heroic developer in the true sense of the word - willing to set aside personal beliefs for the sake of a project and not concerned about being in the limelight - just wants to get the job done right and like a true hero does not care if they don't get all the groupies :)

@SteveB: " talented, brilliant, yet arrogant and prone to tantrums/room trashing." - that pretty well describes me in my early twenties. Speaking only for myself, it was a fear based way of living. I was a control freak and at my level of experience, I knew if I didn't keep control, everything would go wrong and I'd get all the blame. I wasn't into sharing credit OR blame. I didn't ask anything of other programmers except to stay out of my way. I did a brief 3-year stint working for (to me) a larger company where I was on a team of 6-8 programmers. We had some brilliant leadership for part of that time - one of the best motivators I've ever known. It was a lot of fun and I did enjoy being surrounded by smart people. But it's been the exception rather than the rule, and not everybody was smart. One kind of "hind tit" part of the project was given over to a guy who clearly didn't know what he was doing, and I smelled a bailout, so I boned up on what he was working on, looked at his code, and realized it wasn't salvagable. Sure enough, when the guy suddenly quit, guess who his mess got handed to. I had already gone over it in my head, and I quoted two weeks to rewrite his garbage, or 8 weeks to *attempt* to fix it. After a requisite "walk through" just to have someone less qualified review my plans, I got the green light to rewrite. While it wasn't a high risk, mission critical part of the product, it did need to be there in order to release, and it would be embarrassing if it didn't work. My rewrite ended up taking exactly two weeks and came out of QA with far fewer issues than any previous version - which had been flailed on for two years by several different people. Alas, I couldn't stay at that job - the company was being groomed for sale and eventual dismantling, and they were demanding 70 hour weeks for no particular purpose and I was already losing money just to show up there 40 hours because my side business was making considerably more money. Some of the people I worked with there went on to bigger things... MUCH bigger things. It was a great experience, but it went gradually from great to tedious to unbearable.

Whateva ... as long as they aren't dirty politicians, fix their bugs and complete their work on spec, within budget and on time.

Rockstar?... Psssh... that's just a term they made to glam-up the truth of the matter. That phrase refers to a younger coder with a decent work ethic, who can be mentored easily, has decent Google-Fu, whose work can be had at a steal of a price... they've not yet developed a good enough social life or social skills to care enough about having freetime. They don't need freetime to tackle all the DIY shit being a home-owner requires. They're not parents yet (again, no social life). They are still young enough that there bodies don't yet display/feel/exhibit the affects of the high seat-times they are being extorted into doing because they want to make a name for themselves so they can get off being on the damn phone handling support issues. Yeah... he's your little Rockstar because he excitedly has his eyes on the prize of actually attaining the title of Software Engineer and he's not gonna let a little thing like sleep (or chasing after a mate) get in the way.

RE: Degrees vs. certifications. Don't ya just like how whoever it was above that happened to casually mention they had two degrees and thought "certifications" were just a bunch of poo. I'm just going to put it like this... for whatever reason, in the experiences I've had soo far from '92 until now... whenever I've met (alleged) programmers that had a degree... majority of the time it blew my freakin' mind that somebody THAT slow and not "with-it" somehow managed to snag a piece of paper (graduate) from college. Also let's face it, this job is all about continuously doing your homework and studying up on the next new thing since the tech is always evolving. So every year that's clicked past since you got those degrees makes them have less worth anyway. Unless your work history can show and prove you've been on projects specifically utilizing X, Y & Z. A cert in X, Y & Z is going to do more help at getting your foot in that door for an interview than that degree will. Seems to me anyway. But there again... I know many corporate jobs will require it because it looks good to investors on paper that all the people on their team have BS. (pun intended) ;)

Great insight - thank you.

Where do I buy the "i" t-shirt?

The Rockstar Team reminds me of a blog post by Matt Might titled Classroom Fortress. He basically maps the nine types of students in a class to the nine kinds of classes in Team Fortress 2, and makes some notes on how they help (or hinder) a team in general.

I think it can easily be adapted and applied to general software engineering teams too. Each team member has a certain "class" and the best teams have the right balance of classes.

http://matt.might.net/articles/nine-kinds-of-students/

Well worth a read.

@Flanderson:
"Dependency injection is a bad thing in practice. It makes for softwares that are very complex and extremely difficult to debug. Any framework that enables this, including Castle Windsor, is harmful in my opinion."
I'm using it and I tell you it made my code a lot simpler and cleaner. No longer logging code all over the place (Interceptors). We use interceptors to log performance statistics too (update performance counters). And I wonder how you create testable code (unit tests) without some kind of dependency injection? I know you don't have to use IoC framework.

"The same goes for NHibernate."
I never used it but I know a lot of people do. There must be a reason for it.

"Don't even get me started on NoSQL databases! My Good Lord! Not having a schema is only for the lazy. Not having a proper query language is only for the ignorant. Anything we can do with a document database can be done better with a relational database. Document databases and NoSQL databases have no reasons to exist for almost all use cases."
I also haven't used NoSQL databases. But they have proper query language - LINQ. I don't know what you mean by better, but for sure you can't have faster queries in relation database (joins!) than in document db's (read one document). You can head to Ayende's blog and see some performance comparisons.

I think that you have wishful thinking and miss the point. Rockstars only have to do ONE song well and then just repeat it over and over again ONLY while on tour. Else they can sit back and the checks roll in nicely for what can be quite a fair amount of time.

I think that a more appropriate analogy would be that of a miliary situation. The Greek Heraclitus said, "Out of every one hundred men, ten shouldn't even be there, eighty are just targets, nine are the real fighters, and we are lucky to have them, for they make the battle. Ah, but the one, one is a warrior, and he will bring the others back." Thus, really only 1 out of 100 is a real warrior and leader. And only 10 are real survivors. The rest essentially are just there to die.

When applied to developing software, I think that it is more like 1 out of 1,000. That's why you've probably never met any "Rockstar" programmers although the some (a few) commenters have. I think it is more like being a commando type survivalist because most teams are not as good as they think they are...And commandos get things done quick and efficiently. They also survive where others don't.

For gifted combat pilots there's something called the "Wingman Syndrome". That's where your kill ratio is outstanding but no wingman can keep up with you in battle so you keep losing your wingman. And then no one wants to be your wingman because they can't keep up. Very, very few people are commando developers. And the vast majority of developers are really just programmers "writing" not engineering code. And they can't keep up. And teams? They just slow us down. I've put together one excellent team and worked on another but nothing in this corporate environments of today support the formation nor the continued existence of good to great teams.

So to make the statements that you have...You have to face the fact that either you're trolling for comments and/or you are not a rockstar developer or a commando developer. And will never be.

- Grant

What metrics Mr. Hanselman would you consider to be an actual measure of a software developers skills. Say that you have eight weeks to measure the skills of a developer, what tasks would you choose and how would you measure the "test results"?

So the bottom line, as Andrei Volgin suggests, is what evidence do you have to reject the null hypothesis with an acceptable level of confidence?

Consider the possibility that there are developers that have "Grand Master" level equatable chess playing skills. There definitely are Grand Masters of chess - but these individuals are generally nice people - that play chess remarkably well.

Say there are around 10 distinct levels of tournament chess playing skills, and that 4/5 times - at each level of skill difference - a match is won. Would you say that someone at levels 8-10 is possibly a "Rock Star" chess player? Why would this not this then apply - in principle - to Software Developers?

Of course I am speaking about a "Rock Star" here that is humble but also know their capabilities. There are truly Software Developers that should be paid extremely well - because they are truly extremely good at what they do.

By the way playing chess for 20 years does not make one any better of a player than being an "experienced" software developer does.

Anyway, I respectfully disagree with your position based on anecdotal evidence.Since you made the claim - please empirically prove it.

Regards,

Michael Baun

@Winston, I hear you. Been in that kind of position myself and didn't handle it with much tact unfortunately ;)

As the years pass by I find more and more that if you can't work selflessly within a team, then you can only go so far and worse, you will end up stagnated and get overtaken by the new fangled rockstars who play rubbish music and dress silly :)

My own "waking up in underpants in a pile of puke" moment was debugging code that when I had written it months previously had seemed like it was a beautiful gift to the universe, except that now it was more like sh*t on your shoe because it plain sucked...I distinctly remember thinking to myself, "what frackin idiot wrote this....oh, right..." That's when I knew that I could either go on believing my own hype, or change tack and see what if I couldn't learn from others; I always really believed I'd never have that moment where I was the real WTF, but there you go, and I'm glad I did...

And I haven't looked back! Now I don't really mind conceding a point during a technical argument about whether pattern X or Y is "better" for the job or whatever, I find myself able to step back and take a more holistic view of the projects I'm working on and actually help other people whilst maybe learning something new as well.

My attitude now when I join a team is "we will succeed OR fail together" and there is no room for rockstars, everyone on my team is a hero in their own way. It's working out well so far.

Now I gotta go watch "The Rocker" again. It's a pretty good analogy....

I assume you are talking about the social forces at work on a team Mr. Hanselman vs. the actual capabilities of some developers - which can in fact be at a "Grand Master" level.


The only reason I am commenting on this blog entry because I have seen the same reasoning used to justify developer pay scales. Pay scales are - in my humble opinion - a myth - at the upper levels of ability.

Regards,

Michael Baun

I disagree. There are outliers on the bell curve who are 10x more productive. They produce awesome high quality code that totally exceeds your expectations. If you have not had the privilege of working with them then that's a shame, but it doesn't mean they don't exist.

A different question is whether or not those people need to be celebrated and have awesomeness banners hung on their walls, be given 'mvp' awards,....

There I would agree, all good devs are motivated by the work not by silly rewards. They like to see their stuff ship and used. In particular they would hate to see themselves being used as whips for other devs. THey are not and do not want to be treated as stars

Great post Scott,

This is real, I think the same thing :)

Congrats.

Although this article makes very good points, and I agree with most of them, I still cannot help but feel a hint of "sour grapes" in the message. In my experience there ARE real exceptional developers who, not only "know" what to do but, actually DO IT with extraordinary heart, finesse and ultimately concrete resolution. To dismiss them with such derogatory names as "rock-star" (especially with the attendant context) tells me that you probably need more training (or something... :-) Cheers !... :-)

I liked your concept of making a problem disappear.

Rockstars are fake, so I don't think this is a very useful model for work. Or maybe it is. Maybe you are on to something. Maybe much of the current world of technology is fake.

On this I disagree with you Scott. The post convey a nice message but it doesn't describe well the truth.

How many mathematicians to demonstrate the last Fermat theorem? You need to have one rockstar for that, his name is Andrew Wiles.

How many language designers to replace one Anders Helsberg and design a great language like C#? You need to have one rockstar for that (helped with truly good designers but without a doubt, he is the man)!

Of course most programming tasks don't reach such high level of complexity and abstraction. But according to me the same reasoning applies.

I think there is a certain maturity level that goes along with these terms.

Sorry I have to disagree... there are musicians who play in cover bands, musicians in garbage bands who never make it, songwriters who labor night-after-night and are lucky enough to sign a professional record deal and make one or two forgettable albums. Then there those who are transcend their genre (insert whoever your personal music idol),

There's a guy in my office has a personal story of a time in the late 60's where he got to play on stage with Jimi Hendrix in a hole-in-the-wall club in the East Village. Jimi was so trashed that he could barely hold his guitar. For one night, for one song, some 17 year old kid who fooled around with the guitar as a hobby was better than a guy whose body of work speaks for itself.

You are correct, when it comes to moving files from your local machine into production, making a simple stored procedure tie into N- tier architecture, or debugging a broken method in production, there is little difference between a rockstar programmer and your cover- band programmer.

Just as any musician can tune their guitar and play the major cords, there are numerous tasks that a junior programmer does just as well as an architect. I can think of hundreds of times in my career when I witnessed a junior team member give the correct answer and the technical lead was dead wrong.

However if you don't see there are severe and significant differences between professional programmers, you're probably in the class of guy who labored their way to professional status and put out a couple of mediocre software packages rather than someone who is a true visionary in the field.

What the rockstar programmer does is continue to use the same methods they wrote 8 years ago because they are just as relevant today as the day they were written, create truly OOO components that dynamical expand the frameworks in which they are built, always have their next project 40% complete because they understand the business behind their systems well enough to plan the future, and find real value in their product in areas that no one (business analysts or SME's themselves) else even imagined as a requirement.

Really what you should focus on is finding a record producer (* cough, cough - project manager *) that frees the shackles of the day- to-day grind and let them do their visionary work. Cause when you have a rockstar developer just playing scales all day long, you're not making records, you're just making a lot of boring noise.

I agree to disagree because I AM a Rockstar software developer. What do y'all have to say about that?

I am afraid I have to disagree. Just as there is in any profession or team, there are some people who are clearly better than the others. Winning teams are able to leverage the greatness of these people and those great players are able to make others rise up to their level. Great developers make the poor developers around them better. Those great developers may not always be 10x better than the rest, but in my experience those developers are the difference between a project's failure and a project's success. I for one want as many of those on my team as possible!

I know some developers are many times more productive than average professional programmers. The best are consummate problem solvers. They don't have to know the specific computer language that needs to be used or have spent many years in that specific application field. They take in the information, ask questions of the people who do have that application knowledge, and then solve the problems. Even more than being many times quicker, with better code, they can solve problems that average developers can't, even if they were given 100 years.

If you want great programming, then you must use great programmers. The rest of the companies that don't are just wasting their money.

True rock star programmers must have a large experience (at least 20 years) and a diverse programming background. There are many pitfalls in programming that only experience can show how to avoid. There are probably many brilliant, young and smart programmers but without a very experienced leader to point them in the right direction, they will never get to the right destination, regardless of their programming speed.

Experience doesn't always create rock star programmers but it is a necessary attribute.
Problem solving is the most important attribute of a very good programmer but curiosity, energy and an attitude of never giving up on a problem, are also are essential.

I have worked with plenty of "Rockstar" developers. Unfortunately about 50% of them were anti-social contrite douchebags who no-one on the team enjoyed working with and who think their way of doing things is the best and only way of doing things. They act like mentoring others is a nuisance and long ago passed from the realm of confidence into arrogance.

Personally I would hire based on fit over technical skill any day, assuming that someone is competent to do the job and willing to learn more, but maybe not an elite/borderline-genius level developer.

To those elite devs who ARE out there helping others, making their teams better, posting to blogs etc, kudos to you, you do the world a great service by spreading your knowledge and/or remaining humble.

I used to be a rockstar. Now I'm one of the roadies. But that's OK because I still get the girls.

◾Rockstar Engineer - Makes complex problems disappear.

I disagree with this in many ways. First, I've never known a problem to 'disappear'. It might go away from a little while but it'll just come back in another place or form. Developers that are skilled a making problems disappear are often valued and have very good job security but I'd trade them any day of the week for someone that educates the rest of the developers about the nature of the problem and works to foster a collective knowledge of how to avoid it in the future. The "Rockstart" that sits in his office being a hero is worth less than the Junior developer that is motivated to work on a team. Based on this I'd change the characterization to:

◾Rockstar Engineer - Used problems to turns Juniors into Engineers, Engineers into Senior, and Seniors into Rockstars.

Am *I* a rockstar? I'm a competent Senior Engineer who is also loud. I've been on a lot of successful projects in the last 20 years and I was never the smartest guy in the room.

This changed my opinion of you for the better. You can come across as rather arrogant sometimes. Like you were a rockstar or something. :)

I agree that hyperbole (in this case, Rockstar) is not useful, and for the reasons you stated. I'm slowly learning as I get older that not only do I constantly expect "more" of myself, "more" is going to happen at a slower pace than it was in my 20s when I thought I knew everything, whereas now I realize I know very little, in comparison to the knowledge that's out there, but can contribute a lot.

Isn't a rockstar programmer just an exceptionally talented programmer? Does it have to mean anything more than that? I don't understand the purpose of this post, to be honest. You're not really backing your statement up at all. In fact, you contradict yourself by providing the equation for a rockstar programmer! What exactly are you even trying to say here?

Simple, the purpose of this post is that mid-management needs to justify its existance and negate the developer role, so they can take the credit themselves.

Everyone that still codes knows the reality well, no need for discussion. Developing doesn't work like an assembly line, works like a music band.

Companies spend a lot of muscle trying to take away "the technical ownership" of the project from the developers (incremented management tasks + software practices to make them replaceable/fight turnover) and trying to centralize "the ownership" in some well compensated loyal persons. In this way it's still cheaper than having to compensate the developers well. They try to make music using assembly line mechanics.

BTW, I belive in the Rockstar team too: it's just a team of Rockstar developers that share a common interest and can interact. But don't be wrong, you can't make a Rockstar band with untalented musicians.

@Rara Agree with your assessment of the current state of affairs of how developers are "managed" by most companies. True leadership is rare these days. Fortunately, innovation is still alive and well and will ultimately will win over the "pointy haired boss culture". In the mean time the culture war rages. I think we both know who the winners will be!

If you feel to be a rock star in a team this could means two things:
- the team has very low competence (emotional, technical )
- you are growing more fast than the others

You have only two way:
- try to grow the team in competence (emotional, technical ) to reach your level. If you fail go to next step
- escape to another team where YOU are the junior so you have more and more to learn and you can grow again !

The team help you, you have to help the team... But.... You are not married to the team!!!

@Michael Brown Thinking about it this is probably why most of the great programmers don't work at Microsoft. Microsoft culture just doesn't want to pay superior talent that well. Instead Bill Gates complains about a lack of H1-B Visas and developer pay. Bottom line is the denial of the existence of these people is necessary to promote their agenda. Scott is just doing their political will and may not even be aware of it.

Just some thoughts for you Scott!

The most significant problem with the term "rock star" is that many rock stars are considerable flash with no substance. Running neck/neck for stupid title is "Ninja". The last thing anyone should desire to be known as is an assassin from the lowest caste of society.

Awesome Post :)...Simple solution to complex problem is what makes good developer... as Albert Einstein said...."Make every thing as simple as possible but not simpler".

Scott,

All the stuff you write is very good, this one hit it out of the field.

Excellent.

whatever.................you rocks

I like the way you present MVC and other stuff...
you are simply awesome

An old blog post of mine on the topic (YOURS is spot on):

http://recruitinginferno.com/2010/12/23/hire-a-rockstar-no-thanks/