The Myth of the Rockstar Programmer
The Myth of the Rockstar Programmer is just that, a myth. It's an unfortunate myth for a number of reasons.
- It sets an unreasonable expectation for regular folks.
- Calling out rockstars demotivates the team.
- Telling someone they are a rockstar may cause them to actually believe it.
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.)
Brooks's law: Adding manpower to a late software project makes it later.
The Rockstar Developer is a Myth
People love to say that a rockstar can do the work of 10 regular engineers. That's just nonsense. 9 women can't have one baby in a month, and 10 "rockstar" developers can't replace 100 regular ones.
I hate Quora so I won't link to them, but here's a modification of a great answer from Nate Waddoups that was taken from some internal engineering paperwork:
- 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.
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.
Senior + Loud != Rockstar
In my experience, in fact...
Senior + Thoughtful == Rockstar
That may or may not include being loud. Just because someone has written a blog, or a book, or speaks well doesn't mean they are a good developer. You certainly don't want a diva. Diva Developers do more harm than good.
Are rockstars about lines of code? No, good developers solve problems. More specifically, they make problems go away. They fix problems rather than complaining about them.
The Rockstar Team is Reality
In fact, it's diversity of thought and experience in a team that makes a Rockstar Team - that's what you really want. Put thoughtful and experience architects with enthusiastic and positive engineers who are learning and you'll get something. If you insist on calling someone a rockstar, they are likely the team's teacher and mentor.
Jon Galloway says:
Pairing "step back and think" devs with "crank a lot of pretty good code out" devs is a recipe for a good team.
Build smart, diverse teams. Build rockstar teams.
UPDATE: I was just told about this post by shanley on the "10x Engineer." It's a great and detailed piece and you should check it out!
Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.
Great stuff. Thanks 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.
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
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
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.
'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'.
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."
That would be great if you were introducing your evidences to make your opinion more reliable
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 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.
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.
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.
There's no bottom to how worse a programmer can be.
There're certainly programmers who are 10x better than others.
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.
"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.)
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.
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.
- 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.
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.
He is both loud and create a lot of usefull code :) - Castle Windsor, NHibernate or RavenDB.
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.
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.
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.
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 :)
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 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.
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.
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.
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.
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.
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.
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.
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.
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 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.
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.
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 :)
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) ;)
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.
Well worth a read.
"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 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.
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.
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....
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.
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
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.
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.
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.
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.
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 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.
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.
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.
- 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!!!
Just some thoughts for you Scott!
All the stuff you write is very good, this one hit it out of the field.
Comments are closed.
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.