>Yes, relative skill and productivity between programmers can vary wildly, but I would posit that most of the difference you see between organisations ability to deliver software has nothing to do with how many “10X developers” you have hired and everything to do with culture.
Peopleware actually covers a study where standardized programming assignments were handed out to developers for them to take back to their offices and complete. The programmers were asked to time how long it took to complete these tasks.
There was dramatically more variance in completion time between organizations than within any one organization.
Agreed. I once worked with a programmer that took 3 months to figure out how to send a socket message... She had "30 years" of programming experience and refused to let me help her.
It's pretty easy to be "10x" (or infinity) someone who clearly doesn't know what they are doing.
However, assuming some minimum baseline of having a clue, the multiplier is more likely to be due to environment.
Banks hire some very smart people, yet are historically aweful at delivering software.
Startups, especially outside SV often have to survive by hiring "scraps" for peanuts, yet run rings around big corps.
If a company forces people to work with their hands tied behind their backs, they shouldn't be surprised results are lacking.
> However, assuming some minimum baseline of having a clue
What does having a clue mean though? Being able to code a loop? Fizzbuzz? SQL? Google for stuff? Architect a small program, a medium program, or a large program? There's a huge variation in cluefulness -- which is entirely the point.
That's just a lack of experience talking? There are many opportunities in a large project to get stuck or go down a blind alley. Even folks with a clue can do it. Someone who avoids these pitfalls can get far more done. You will inevitably meet one of them in time.
Minimum clue level? How about the minimum level is "the level a lot of developers are making a professional living at". It's incredibly low. I've personally done things in a week that previous developers had spent several months on, and I had no particular domain knowledge. And I feel some other folks are far better than me. So the entire range could possibly be 100x.
I've had small coding issues where one dev takes a path that costs them an hour or so, and another is able to deliver the same functionality in minutes.
I've seen projects where some developers simply say " I've no idea on even how to start such a project ", and other developers sit and think, read, and end up delivering. That's far more than 10x.
Environment may be huge, but it's blatantly false to say there is not a massive, order of magnitude difference between individuals. Unless you define developer as meaning within a certain competency bracket. At which point it's only true on definition.
I will argue that a big difference like that is caused by the environment: looks like is failing to grow skills, motivate and foster collaboration, and if there a few that are truly clueless, failing to proper hire/assign.
The summary of the issue by gnat at http://programmers.stackexchange.com/questions/179616/a-good.... is quite good. I find McConnell's argument on "10x" (as a shorthand for "4x-20x") more defensible, and distrust the modality argument made by Bossavit, though Bossavit has additional reasons for why 10x is inappropriate.
Unless there's been new research in the last 4 years or so, I don't think there's anything more to say about this topic than what those two have written.
That link has some good references and conclusions based from data. There is a very likely chance that professional programmers can have an impact that is many times that of their colleagues.
The original article is the author's anecdotal evidence that a 10 times difference in productivity is caused by environment. It's enough to generate a hypothesis, at least. After reading a few of the references, I've found it's even harder to generate good data for this than I expected. It would be of no surprise to me that environment is a large confounding factor on what generates these "10x" programmers.
People asking for code samples from me run up against the NDAs that I've worked under (code never to be seen by anyone else) or that I don't really care about the code that I write for me and don't bother storing it on github.
I think you're conflating the notion of value and productivity. I'd argue value is far more subjective than productivity is. i.e. Facebook is maybe worth $200 billion today, but with a change in the market may only be worth $100 billion tomorrow. Whereas productivity (lets say some ratio of features, bugs, time) is more objectively measured and less volatile.
It's unclear if Facebook's success depends (at all) on the choice of implementation language (beyond picking an obvious loser, which C is not, in the right hands).
I do agree with the author that a 10x environment is required for a 10x programmer.
I was a 4x-5x programmer at my last position relative to my co-workers. However, I was fired after I tried to take my government legislated vacation entitlement after 3 months notice (and after the employer lost the right to dictate when I could take the vacation). The threat of firing also came with a promotion without additional pay. Bureaucracy, & labour violations in the pursuit of profit has created a <1x environment.
Mine is somewhat of an extreme case, but anyone will lose any motivation to outperform without commensurate pay/recognition.
I don't think it automatically follows though that 10x environment leads to 10x programmers. I have now, in my career, come into perfectly fine organizations where hardly anything got done. A serial history of 0.2X programmers in an environment that didn't limit them.
So I completely disagree with the premise of the article. The 10X programmer exists and environment, while a factor, isn't the only factor.
That's not what he is saying. His header is: "There is no such thing as a 10X developer (without a 10X environment)." It's p->(q is possible), not p->q.
It's literally the first line of that section, the topic sentence of the paragraph it's contained in, and that paragraph is a defense of that premise. Hardly cherry picking.
Ultimately though I feel like the flaw of the argument is the idea that there are all these great developers sitting around constrained by their environments. Great developers would be constantly frustrated by poor environments and would either change them or move on. What really happens is that these poor environments attract poor developers and nothing changes.
Certainly no company can go out and hire and rock star or a ninja or whatever and save their organization if the organization is terrible. It could work, and it has worked, if the organization is willing to change. But more than likely said 10x developer would just move on when they couldn't affect the change necessary to produce 10x the output.
And that is not really true either. Many years ago I worked in the federal government and there were quite a few 10x developers and teams holding everything together despite the pretty poor environment and overall low quality.
Yours is not an extreme case at all. In fact, this is standard fare in the industry, but nobody wants to admit it happens to them because it's embarrassing.
Europe has very strict vacation policy (mandated 5-6 weeks), healthcare benefits and employee protections (hours worked, overtime pay, etc). I wonder why that is? Western Europe isn't exactly a developing region. Maybe they realized that you can't give employers all the power and expect them to act benevolently at the expense of profit.
American work laws are dystopian. Being an employee in the USA is sheer stupidity. PG says as much during his essays. I always find the "Who's hiring" threads comically ironic on HN.
We're here not to be employees, but to become entrepreneurs.
There are lots of thing in that comment that indicate it is not a USA based employee at all. For instance, I don't know of any jurisdiction in the USA that has a vacation mandate.
So, that isn't to say that USA's work laws are good, only that European style work laws are not enough to prevent abuse.
The difference is that if Europe/Canadian workplace laws are being violated, you have recourse, which means you don't have to choose between 'whatever the employer decides to require' and 'quit my job and suddenly have no income'.
> I always find the "Who's hiring" threads comically ironic on HN.
> We're here not to be employees, but to become entrepreneurs.
And you don't find ironic the fact that most entrepreneurs need employees (that are usually paid substantially less than the value they create, in line with all other companies).
All of these terms just seem designed to haul in the people with the biggest egos. You're not just a widget, working on a computer, producing results. You're on stage, with lights and speakers and a crowd cheering your name! You're world famous! Go you!
I have no interest in being a 10x rock ninja. I'm happy being a programmer, or 'engineer' if I want to feel especially fancy.
> I was a 4x-5x programmer at my last position relative to my co-workers.
Somehow I have a hard time believing anyone who judges their own skills themselves. Dunning-Kruger comes to mind. Especially when being fired after barely 3 months.
Having no open source projects to show off = nothing special.
Having projects to show off = something that makes you stand out.
There's no way around this. I can understand why people haven't got open source projects to their name and that's fine but that doesn't change the fact that those that do will look better in interviews.
Have you measured this assertion in anyway? I'm not making a claim one way or the other, but what I have found is that people's perceptions about what is indicative of good candidates is rarely what is actually indicative and data goes a long way to dispel/confirm myths.
I agree that the negative's are a very difficult case, but in my experience is that most people don't cover the easier case of candidates they can evaluate. Further, evaluation techniques themselves are pretty error prone. But without collecting data and experimenting with it, how do we improve the problem?
But that means that you don't actually know if this extra signal of quality (or at least, notability) has any value at all. That tells me that you shouldn't be including it in your analysis of a candidate if you don't know what it actually represents.
It's taken me from working in an obscure company on an obscure project into being at least somewhat heard of in the specific field. People are using this in lots of projects and it's been ported to many other languages. It's opened up networking with others in the field and in interviews I've had people state "yeah we looked at your code, it's really clean and efficient".
In my own experience, folks with blogs or public projects are great to interview because it makes it a lot faster to skip past the basic bozo filter of whether or not someone can code at all (fizzbuzz, etc.) That's fantastic because that's one of the suckiest parts of interviewing in general, but so often necessary. But that rarely tells you how talented someone is.
Maybe, but most of the studies (I'm thinking of Peopleware's examples) indicate that the environment is the dominant factor and the difference in people is mostly noise.
Do they really though? Have they consistently shown you can take the developers in a bad environment and put them in a good one and they will be as productive?
I don't think so. I think they have simply shown that certain environments are horrible for productivity.
I'm not sure I agree with this article in it's entirety, however there is one thing I agree with. Environment matters.
The environment created will make an all the difference. And it's not things like beer and ping pong tables, it's respect for employees and encouraging an environment of collaboration. It's about making your developers excited to be working for you.
This seems like common sense, but in my 15 years I've only worked for a handful of companies that really "get it" to some degree and there is always a higher amount of productivity there.
Oh wait, a recruiting firm is dissing the data which makes recruiting firms less useful? I am not surprised.
Sadly one of the most influential things I've found on how successful a developer will be at a company is how they like to interact at work and how the folks at work prefer to interact. And that is something recruiters can't search for.
I couldn't agree more. I've watched folks come and go in the various jobs I've had, and aside from one very painful case, most of them moved on due to cultural incompatibilities and not incompetence.
I feel like the "Github is not a CV" posts are about as tired as the "Why I'm leaving X" posts at this point. Honestly, if the place you're applying doesn't want your Github account, they wont ask for it. If they do they will. There's no right answer here.
Me, personally, I love using Github as a CV because it saves me the banality of trumping up my chest feathers and getting ready for a show that a resume/CV requires and lets me keep working on things that I'm curious about.
The article basically died after saying stuff like:
>Spring Framework is undoubtedly one of the most popular software libraries/frameworks in the history of mankind, yet it is an abominable bag of fail and poor engineering.
Typically when you say something like that, you'd actually know what you are talking about enough to state concisely and easily your reasoning.
"Productivity" is the wrong metric to measure for developers anyway. Development is not a factory job, developers aren't cranking out widgets on an assembly line and developers who crank out more widgets aren't somehow superior to those who crank out fewer.
What matters is the value of what devs have created, and that's almost impossible to measure objectively in many cases, with some occasional exceptions. That often takes a lot of work and usually requires someone who is also highly skilled making a subjective judgment. I complete agree with the author here, hiring and culture is hard, and most of the time that fact is ignored and the result is failures on both counts. Taking the time and effort to be good at either is usually a huge competitive advantage.
It's similar to software. Does your product solve easy problems or hard problems? If you only solve easy problems, how do you expect that to keep you ahead of the competition? Determining the talent of a developer is not an easy problem in the general case, and if you only hire the developers that are easy to hire you're probably doing it wrong.
64 comments
[ 2.8 ms ] story [ 122 ms ] thread"though I fear they where actually real conversations"
There's no author name on the post, in fact there's no name on the entire site. Even the Domain is registered anonymously (DomainsByProxy).
I don't care for names anyway, but there's no links to any external identity or previous work either.
All I see is an anonymous PR blog, seemingly trying to stir some random internet controversy for backlinks.
Knowing someone's name is not a requirement for assessing the quality of their argument, and whether their observations match your own.
That doesn't jibe with my experience at all.
There was dramatically more variance in completion time between organizations than within any one organization.
BTW, the book is worth reading.
However, assuming some minimum baseline of having a clue, the multiplier is more likely to be due to environment.
Banks hire some very smart people, yet are historically aweful at delivering software. Startups, especially outside SV often have to survive by hiring "scraps" for peanuts, yet run rings around big corps.
If a company forces people to work with their hands tied behind their backs, they shouldn't be surprised results are lacking.
I don't think this is true. It's quite common to have a huge productivity variance between people on the same team.
What does having a clue mean though? Being able to code a loop? Fizzbuzz? SQL? Google for stuff? Architect a small program, a medium program, or a large program? There's a huge variation in cluefulness -- which is entirely the point.
I've had small coding issues where one dev takes a path that costs them an hour or so, and another is able to deliver the same functionality in minutes.
I've seen projects where some developers simply say " I've no idea on even how to start such a project ", and other developers sit and think, read, and end up delivering. That's far more than 10x.
Environment may be huge, but it's blatantly false to say there is not a massive, order of magnitude difference between individuals. Unless you define developer as meaning within a certain competency bracket. At which point it's only true on definition.
Unless there's been new research in the last 4 years or so, I don't think there's anything more to say about this topic than what those two have written.
The original article is the author's anecdotal evidence that a 10 times difference in productivity is caused by environment. It's enough to generate a hypothesis, at least. After reading a few of the references, I've found it's even harder to generate good data for this than I expected. It would be of no surprise to me that environment is a large confounding factor on what generates these "10x" programmers.
I was a 4x-5x programmer at my last position relative to my co-workers. However, I was fired after I tried to take my government legislated vacation entitlement after 3 months notice (and after the employer lost the right to dictate when I could take the vacation). The threat of firing also came with a promotion without additional pay. Bureaucracy, & labour violations in the pursuit of profit has created a <1x environment.
Mine is somewhat of an extreme case, but anyone will lose any motivation to outperform without commensurate pay/recognition.
So I completely disagree with the premise of the article. The 10X programmer exists and environment, while a factor, isn't the only factor.
Ultimately though I feel like the flaw of the argument is the idea that there are all these great developers sitting around constrained by their environments. Great developers would be constantly frustrated by poor environments and would either change them or move on. What really happens is that these poor environments attract poor developers and nothing changes.
Certainly no company can go out and hire and rock star or a ninja or whatever and save their organization if the organization is terrible. It could work, and it has worked, if the organization is willing to change. But more than likely said 10x developer would just move on when they couldn't affect the change necessary to produce 10x the output.
Europe has very strict vacation policy (mandated 5-6 weeks), healthcare benefits and employee protections (hours worked, overtime pay, etc). I wonder why that is? Western Europe isn't exactly a developing region. Maybe they realized that you can't give employers all the power and expect them to act benevolently at the expense of profit.
American work laws are dystopian. Being an employee in the USA is sheer stupidity. PG says as much during his essays. I always find the "Who's hiring" threads comically ironic on HN.
We're here not to be employees, but to become entrepreneurs.
So, that isn't to say that USA's work laws are good, only that European style work laws are not enough to prevent abuse.
> We're here not to be employees, but to become entrepreneurs.
And you don't find ironic the fact that most entrepreneurs need employees (that are usually paid substantially less than the value they create, in line with all other companies).
All of these terms just seem designed to haul in the people with the biggest egos. You're not just a widget, working on a computer, producing results. You're on stage, with lights and speakers and a crowd cheering your name! You're world famous! Go you!
I have no interest in being a 10x rock ninja. I'm happy being a programmer, or 'engineer' if I want to feel especially fancy.
Somehow I have a hard time believing anyone who judges their own skills themselves. Dunning-Kruger comes to mind. Especially when being fired after barely 3 months.
The parent mentioned 3 months notice prior to taking holiday/vacation, not 3 months of employment.
Having projects to show off = something that makes you stand out.
There's no way around this. I can understand why people haven't got open source projects to their name and that's fine but that doesn't change the fact that those that do will look better in interviews.
The following very simple project has helped me immensely.
http://www.reddit.com/r/programming/comments/281msj/fast_off...
It's taken me from working in an obscure company on an obscure project into being at least somewhat heard of in the specific field. People are using this in lots of projects and it's been ported to many other languages. It's opened up networking with others in the field and in interviews I've had people state "yeah we looked at your code, it's really clean and efficient".
Also, having developers with a minimum competence, a good business ambiance will make the difference, more than hiring a supposed coder-rock-star.
Surely it takes both?
I don't think so. I think they have simply shown that certain environments are horrible for productivity.
But yes, inversely your 88 Chevy Corsica isn't going impress anyone at Nurburgring.
That being said in any kind of large organisation changing the culture is 100x harder and slower than hiring better developers.
IMO, building/creating 10x programmers in your area of business is simple but it is not easy.
- Ensure at least 25% of your developers times are spent on learning and development.
- Give them the freedom to work on what they think are the most important tasks to the business (e.g. Something similar to open allocation)
- Ensure you are paying your developers at least market+20% in order to minimise turnover so you actually get something out of creating 10x'ers.
Now go and try and change a large organisations culture to be like the above. I'll wait.... And wait... And wait
The environment created will make an all the difference. And it's not things like beer and ping pong tables, it's respect for employees and encouraging an environment of collaboration. It's about making your developers excited to be working for you.
This seems like common sense, but in my 15 years I've only worked for a handful of companies that really "get it" to some degree and there is always a higher amount of productivity there.
Sadly one of the most influential things I've found on how successful a developer will be at a company is how they like to interact at work and how the folks at work prefer to interact. And that is something recruiters can't search for.
I feel like the "Github is not a CV" posts are about as tired as the "Why I'm leaving X" posts at this point. Honestly, if the place you're applying doesn't want your Github account, they wont ask for it. If they do they will. There's no right answer here.
Me, personally, I love using Github as a CV because it saves me the banality of trumping up my chest feathers and getting ready for a show that a resume/CV requires and lets me keep working on things that I'm curious about.
>Spring Framework is undoubtedly one of the most popular software libraries/frameworks in the history of mankind, yet it is an abominable bag of fail and poor engineering.
Typically when you say something like that, you'd actually know what you are talking about enough to state concisely and easily your reasoning.
What matters is the value of what devs have created, and that's almost impossible to measure objectively in many cases, with some occasional exceptions. That often takes a lot of work and usually requires someone who is also highly skilled making a subjective judgment. I complete agree with the author here, hiring and culture is hard, and most of the time that fact is ignored and the result is failures on both counts. Taking the time and effort to be good at either is usually a huge competitive advantage.
It's similar to software. Does your product solve easy problems or hard problems? If you only solve easy problems, how do you expect that to keep you ahead of the competition? Determining the talent of a developer is not an easy problem in the general case, and if you only hire the developers that are easy to hire you're probably doing it wrong.