It's very convenient to think it's a myth or to think that the only way you get to extreme productivity is to be a cowboy, but I have personally seen that it's not the case. Obviously this is just an anecdote, but I have worked with at least one freak productivity monster so I know they can be real.
At one of my employers we had a very large and highly skilled dev community and being quant-biased, we tracked code checkins over time, number of tests written, number of pushes to production etc. I was very proud to be about number 3 or 4 out of about 1000 devs on these productivity metrics consistently over a period of 8 years there.
There was one guy however who literally dominated. Not only was he number 1 on any metric, but he did more checkins than the number 2, 3 and 4 devs combined. He had so many checkins that eventually our glimpse code search index whitelisted his userid because it thought it was a keyword in the language.
And it wasn't that he was a cowboy, he was obsessive about code quality, fixing bugs etc and also was top if you looked at test coverage etc. He was just a flat out machine - every day he would just come in and code all day whereas I have spurts of productivity with downtime etc. He didn't seem to need to be intellectually fascinated by a project and was just as productive at the beginning as at the end of a project - one of my colleagues joked that this guy's interest level in any project was always 83% ("Almost but not quite very interested") no matter what it was. He was very skilled and just churned out massive amounts of code all day every day. He never fell into the classic engineer's trap of overcomplicating things - in fact a lot of what he wrote was very simple when you looked at it (and I think that's part of what made him so good - he had a brilliance for finding really obvious, simple ways of solving hard problems) and because he wrote tests for everything he didn't really need to go back and or refactor things much.
> At one of my employers we had a very large and highly skilled dev community and being quant-biased, we tracked code checkins over time, number of tests written, number of pushes to production etc.
Why are those objectively useful metrics for productivity though? I can think of a dozen reasons why they aren't, as opposed to why they might be. Which, I guess, makes their objective usefulness subjective.
Some people will be working on longer lived feature branches because they're more complex, so they end up with one merge to master in the time it took the dev updating REST APIs to accommodate a new optional parameter to merge four branches.
Someone writes four tests that another dev might cover in one because the four assertions were all closely related to the same invariants and code paths. Who was actually more productive?
One developer pushes to production three times in one day because they typoed a property name twice... ...etc. etc. ad nauseum.
If you seriously believe that these metrics are objective methods of measuring developer productivity, I strongly suggest you spin off a business, because you're about to make millions.
Presumably someone, or some group, was writing all the requirements and acceptance criteria necessary for him to code all day, and they were managing the changes to those criteria as users gave feedback on what he was doing.
And then there were the other devs peer reviewing his code, happily accepting his PRs without needing to add comments or request changes.
And then there was the QA team doing the integration and end-to-end tests, user testing, training, etc.
He couldn't have been quite so productive without those all those people.
That's not to put his amazing work down. No doubt he was brilliant. It's just that we shouldn't ignore the efforts of the people who enable developers like him to get on with what they're good at. Development is a team sport.
I also know that there's the guy that never writes tests, is incapable of writing non reduntant-code, pushes everything to master as a blob of unrelated changes, using git as the backup server, comments are sparse and mostly useless, code is a mess and 'deploy to production' means starting a Jupiter notebook on the Dev machine.
The same guy saves to the company millions in expenses and gets the promotion.
10-20-100x Devs are just very good Devs, nothing that automatically changes the fate of a company
You can have the best guitar player in the World and your band goes nowhere or you could be the Ramones...
The only relevant question is whether that person has a life outside programming and work. If yes, then it's truly a case of remarkable talent. If not, it's a case of sacrificing something in exchange for something else.
As a manager of devs, the times I've seen someone be much more productive than usual have all been where they:
- Understood the requirements. Not just in a specific way, but also by having enough context to know what's likely to come ahead.
- Already have the tools familiarised. So the right languages are in their brain-cache, the CI/CD is familiar, and there's little need to read up on any new frameworks.
- Have already done something similar in the past. I work in the financial space, and the sheer number of wheel reinventions is mind boggling. Feed handlers, orderbooks, decision logic, aggregators, wire protocols. Someone who's been through the grinder a couple of times will know what the fixed points are and what you can change.
All of these point towards experience not simply in time but also in terms of projects done.
I've also come across a handful of people who were inexperienced but thought they could solve all the same problems without the benefit of having seen how others have done it, and it's been a disaster each time. Sometimes these people are hailed as heroes, because management thinks it's somehow to their credit that their Rube Goldberg machine seems to work.
The one or two really good junior staff who "get it" have tended to be the humble personality type. They don't bite off more than they can chew, but they eventually eat the whole cake.
How much of being a 10x dev comes down to understanding the existing system really well and being able to iterate quickly?
I wouldn't call myself a 10x dev but at my last startup I was very productive, definitely more than expected at my skill level, because early on I had a lot of access to the people who designed our (undocumented, untested, and buggy) backend system. Then when I got a feature ticket (consisting of 3 words) I was able to quickly bang it out and deliver it, whereas other more senior engineers struggled because they didn't fully understand how the backend microservices actually worked and talked to each other.
Now I work at a big tech co and I'm in the latter position: I have a hard time understanding our complex CI/CD, and don't have nearly as much understanding of all the existing components. As a result I'm not nearly as productive and back to feeling like a 1x or 0.1x dev.
Of course a 10x dev understands the existing system, but it's more than that. A 10x dev IMO, understands how to logically take apart and put together a system. I find it amusing that we recognize grand masters in chess and elite performs in other fields, but don't wish to acknowledge that such people exist in our fields.
What I have seen with such developers is that they can jump into a system they have no idea about and ramp up faster than most people. I don't believe that everyone can be a 10x, I also don't believe that everyone that can be a 10x is even going to reach that field. From what I have seen, these folks are the sorts that enjoy working on non user centric app. They hate those ambiguities, so you might find them in security, or working on compilers, networking and lower level sort of codes where it's possible to conquer whatever demon that will arise from the code. It's almost impossible to WIN in user centric app where what's correct is subjective.
I took a new job this past fall, and I found our "git push to production" pipeline to be quite opaque. I solved this by taking on small projects to implement incremental improvements: improving log level configuration for production, simplifying database migrations, etc. I learned a bunch about different parts of the system, and it gave me a chance to gain some visibility in a good way. And each improvement helps me feel more productive, and that increase in perceived/actual productivity comes from better tooling or having knowledge of how the system works.
Developer productivity is not linear in function of task difficulty. A 10x developer may be just as productive as a junior if given easy enough task. Or even actually worse, because he could get bored much more easily. It may not be fun to move data from a database to a website when doing it for the 100th time.
In a company I worked for, there were two teams working on the same product: the mobile frontend team and the backend team. The productivity of all developers was very similar, and both teams seemed to be working in lockstep and features were delivered mostly timely without big issues. Until the moment the frontend team hit a serious bug affecting the core functionality. After they struggled with it for a week, a senior Java developer moved from the backend to help them. He nailed down the bug in a day... in third party C code. This is why you need 10x devs, but they may not be immediately visible. A 10x developer is not 10x more productive. A 10x developer can solve 10x harder tasks when 1x developers fail to find answers in stack overflow.
10x performance has very little to do with algorithmic/academic agility, and everything to do with broad knowledge of software engineering, not creating unnecessary tech debt, pro-actively owning and solving problems, and documenting and automating the shit out of things. 10x devs are seldom ten times faster at wiggling their fingers on the keyboard to shit LOC out. It has very little to do with smarts (although there's a bar) and more to do with stewardship, vision, and common sense.
Something this article just can't capture is that many devs add net negative value by being allowed to work in an organization. They create complexity, chaos, and confusion. They might be smart, they might be dumb - the problem is that they have no clue what they're doing within a software organization, and often they don't care. They ship broken code, awful bugs, badly designed systems. They make bad technology choices. They don't measure their work (metrics, logs). They put no thought into anything other than manual W.O.M.B deployments. etc, etc.
It's very hard to not be 10x more effective than a net-negative dev. And then beyond that there are very good engineers who we typically put on the senior -> principal track who are able to get a lot done across a large organization, and generally create a culture and an economy within a company that is conducive to sustainable engineering. I expect the average principal engineer to be slightly slower than a college student on an algorithms problem (depending on the problem). I don't expect a college student to be able to drive cross-organizational software initiatives in a large company. I also don't expect that of most Senior engineers, and I don't think most Senior engineers I've met are even willing or capable of doing that.
I'm not sure I'd trust one dude's college experiment to be relevant in this domain.
Also a net negative engineer in one setting might not be a net negative in another. Where I used to work we had a senior programmer who never wrote any tests, claimed c++ was the best language ever while pushing c++ code with correctness errors, switched to go and wrote an algorithm with stateful variables that couldn't be multithreaded. Yet I'm sure that probably at least a few tines he must have written a few lines code at Facebook that saved them on the order of millions of dollars
Summary: "We took a classroom of students and measured their performance with coding challenges in a situation that bears no resemblance to actual business operations with no middle-management, insane CEO requests, or office politics. The top performers didn't excel at the mundane tasks, and we couldn't find many 10x performers in this classroom of students."
Slight correction: "We took a classroom of students and measured their performance with coding challenges in a situation that bears no resemblance to actual business operations with no middle-management, insane CEO requests, or office politics. We observed that several high-impact comparisons could be made, similar to literature suggesting a 10x programmer. However, we found that comparing a student to himself often results in >10x results, and that other comparisons often used in literature could produce >10x from this dataset, which obviously had very few true outlier talents or performances. Therefore, we conclude that the story is varied and that individual variance overtime outweighs cross-individual variance at any specific time."
Their sample size was 494 students from classes over seven years (they could have included 3800 but wanted to limit it to a shared choice of language). And not for nothing, their students were not your typical newbie grad students - they had an average of 3.7 years of industry experience.
A friend of mine asked me to help him with piece of code. I looked at it and it was all over the place, nest of ifs and loops. To understand it would take me hours so I rewrote it from scratch. Nothing really fancy or overly clever just simple, minimal, straightforward code that followed the assignment. When I showed it to him I discovered that mine had exactly 10x fewer LOC (250 his vs. 25 mine). That wasn't my intention it just happened so. And I know programmers who are 10x more productive than me.
The biggest challenge in debunking that myth is non-tech cooperate positions above developers. Once a cowboy coder delivers results and gets noticed for fixing stuff quickly, it's all over. That person is hailed as a hero and he'll be the first pick for leading the "A-team" of devs to make 2.0 once they realize how buggy and resiliant the current system is to change. This repeats adnauseum in every company I've worked in. The only solution is to embrace a cultural change that's centered around professionalism in software and puts the developer at the top of the org chart.
I think people think of 10x programmers as someone that will rip through your average backlog of stories 10x faster than anyone else on the team. That's pretty unlikely if you're not involved in creating those stories.
I think being a 10x developer is about getting from point A to point B ten times more efficiently. Its not just speed, its reduced waste and smarter planning. To do that, it's not just about coding, it's about deep understanding of the problem at hand. A great developer will be able to recognise things that are superfluous, find shortcuts, know when not to write something, etc. Its not just about coding faster, its about finding the shortest path. So they'll get you to having a completed work item 10x faster, but often by doing it in a way that might not be obvious from the outset to others.
But if you're working in the standard model where a PM is micromanaging... sorry "grooming" tasks.. then you frequently wont get that sort of performance because the developer doesn't have the autonomy. Without autonomy you lose what makes good developers good.
Of course just giving developers more autonomy isn't a panacea, most cant use it, but I think putting people into Scrum situations precludes most "10x" developers from being able to shine.
Agree, basically that is the point. If you have just stupid tasks, everyone will perform the same. Then sometimes you have a challenging problem. A good skilled dev (let us call him 10x) will develop a clean, easy solution on the other hand one not that good dev might just make things extremely complicated and ruin the whole solution. Happens all the time.
A lot of people can write code, but on the path to making a shippable product a ton of programmers don’t have clarity on “what to write next” to arrive at the finish line. It often seems like a product is 80 or 90 percent done, but by the time it is actually shippable as a product, 2x or 4x or more work will be done, and major revisions of the code will happen to reach that point. The real 10x programmers are the ones that have done this enough times that they don’t get distracted doing naive things that will be discarded and redone as often.
I wonder if this study looked at a lot of programmers who just fix bugs or add well-defined features to apps, or really distinguish between those people and people who can build shippable products from ideas.
Most engineers are 0.1x engineers, just trying to remain employed while browsing a lot of HN. Then there are 1x engineers using the rare skill of actually trying reasonably hard and having discipline. (These 1x engineers may eventually experience a significant life disruption, mental or physical illness, or simply lose the feeling of meaning from the work, and subsequently become 0.1x engineers temporarily or permanently.)
There may be actual 10x engineers for short stretches. I may have been something like this for a short period in grad school when I was obsessed, skilled, healthy and knowledgeable all at the same time. But I’m certainly not anymore.
Software is one of those things where the right small changes can easily produce a 10x difference in value.
For example, not having an overflow bug can save your company $millions. Or avoiding a deadlock. Or speeding up your datacenter software by 1%. Or picking the right architecture at the beginning.
I've been coding for 15 years and for some kinds of projects, I'm 10x to 100x more productive than I would have been 10 years ago.
But it's only the case if the project's problem domain is complex enough and I get to design the solution from scratch.
If you asked me to work on an existing spaghetti code project or on a very simple front end project, you wouldn't be able to see any difference at all between my old self and new self.
In fact, my new self might underperform because I would be bored and going at a very slow pace.
There are 10x and 100x developer but you only notice them when the problem is very complex and you give them the opportunity to lead.
The idea that 10x devs don't exist is self-fulfilling in a way because managers who believe that don't look out for these devs within their own organizations, so they don't promote the right technical people and they never get to see that 10x return.
I find it deeply disturbing that many people have no trouble believing that some CEOs are 100x more productive than others but they don't believe the same is possible for developers despite the fact that many software projects are in fact highly complex systems; in the same way that companies are highly complex systems.
I suspect that 10x programmers are productive because they control the abstractions and tools that makes them productive (for example, programming language they use), and write their own that help to solve the problem faster.
If you control for this autonomy, by assigning them small "routine" tasks, then of course the effect is lost.
The paper somewhat advocates an approach to SW development that can easily result in this. If you give people lot of small tasks to be done, they will never be able to articulate that they are actually all very similar and can be factored out into an abstraction.
I agree: once the development process is organized to the level that for every few lines of code three meetings on higher level managers and "designers" have to happen and be signed and the developer just has to write three lines and make ten times more paperwork (in triplicate), and constantly wait for other parts of the organization, no developer can be better than any other, to the joy of the managers, and all developers became provably replaceable. Not because the developer can't do better, but because the whole organization mostly doesn't prioritize effective development.
I however suspect that such an organization, happy to meter the development, would not meter the efficiency of the whole, and especially would not allow comparing that whole to some other organizing model -- it could prove that the managers are the weak point after all.
Yep, I think you've hit the nail on the head here. I've worked with a lot of colleagues that could implement features faster than me, polish off more story points, or wreck me on whatever the metric of the day is, but if we were both CTOs of startups in the same market I wouldn't even break a sweat worrying about them (from a tech perspective).
Most businesses don't have access to top talent and they know it. Most businesses are specifically trying to create an environment where devs are interchangeable, and optimising their processes for the 50th percentile dev (if that).
If you do your measurements within that context then of course 10xers don't exist. But when it's John Carmack vs Scrum Legend #34598295 1v1 on Final Destintation with No Items, I know who I'm betting the house on.
It seems that there would be a huge selection bias in this study. They only looked at programmers taking their course. But wouldn’t the best programmers be much less likely to take a course for improving their skills? So it’s no wonder they found that only a tiny % were very good. We can’t really conclude anything about the population at large from this.
They found no true outliers in this group, but were able to make comparisons which did seem to show fantastic 10x (or 24x) outperformances. From this you may conclude that comparing programmers is difficult and likely to produce misleading metrics.
They found that 95% of programmers had such high variance in their day-to-day that Bob on Monday might be >10x with respect to Bob on Tuesday. And, this variance dwarfed the variance between Bob and Alice, one of whom may be a supposed 10x programmer.
I find the study poorly done as they only looked at people who took a "Personal Software Process (PSP)" course with an average of 3.7 years of experience.
I would assume that people who are extraordinary good at their job will resist taking a course geared towards beginners, so they wouldn't be counted for this study.
> The best are not that much more productive than merely good (on routine tasks).
> There just aren't that many "best performers" available.
> The real world, of course, is far more complex than the limited, controlled study that we conducted.
I think this pretty much sums up why I don't like this article.
They had some real world-data, but didn't really have any interesting conclusions. Obviously someone isn't going to be good at everything, and if they were, there aren't going to be that many people. The issue of individual programmer productivity is very complex, and studies like these are way too abstract to draw any meaningful conclusions.
This is one of those cases where it's easier to talk about things using common sense because it involves things that are easy to break down by the human mind but hard to break down into a scientific theory. We know certain people are better at their jobs, maybe even 10x the average programmer for specific situations. But at the same time, it might just be that the comparison being made is unfair, or the person is good at one specific thing but bad at something else, these are things that have to be evaluated on a case-by-case basis.
People have gotten way too obsessed with the term as as a concept and it doesn't help to talk about 10xers because the discussion is at a high enough level that it's too vague and meaningless. It always just devolves into what even is a 10xer and what if someone is 0.1xer and so on...
The weird thing about the article is that figure 3 clearly shows that some programmers did have consistently excellent performance, but they don't show the relative performance of the top performers, only their rank. We are supposed to infer it from table 1, I suppose, but that only shows the relative performance for the top 5%.
"For the study, we used data from the PSP class programming assignments for which students record effort, size, and defects for a series of programs."
What?
While the data points are nice - I think the author has completely misunderstood the issue here.
I don't think in any given group of young devs there's going to be someone '10x better' than the rest, and this was never want '10x' was meant to refer to.
Though I don't really believe true 10x-ers exist, I have no doubt that senior, competent, experienced, creative and focused engineers who know how to communicate and collaborate are often worth 10x relative to many of their peers.
Particularly in tricky domains, in funky languages that have a lot of room for self immolation, doing non-standard things, a fully competent senior dev who has 'done most of it before' can basically ignore most of the pitfalls, knows most of the little idioms, and can get to solving the problem in a reasonable way, whereas it may take quite a long time for a lesser, junior dev, and may be entirely above the head of others.
I have to disagree. There are people who, outside of any job, discovered programming to be fun at a young age, such as modding games, and if they keep at it, they become at least intermediate-level at a young age. Then there are people who heard coders make good money, studied it in college, and got a job doing it (at a place that doesn't need to pay for, or can't determine, the former type), but wouldn't do it for fun. They know the concepts, but they have a weak link to enjoyment of using them, and only learn what they need as a minimum to make some contribution. They want to like what they do, but it's not easy. The former can easily be 10x more productive than the latter, but they're on such different levels, it's unlikely they'd work side by side so you could compare them. This is ignoring the rare savant who's closer to a 100xer, but I've seen them too.
> I don't think in any given group of young devs there's going to be someone '10x better' than the rest
John Carmack was in his early 20s when Wolf3D and Doom happened. Mid 20s for Quake. I have reason to believe he was vastly more productive than most developers his age. I don't think it's unreasonable to think there are other young developers who are similarly much more productive than the average.
10x or not, I do believe in significant differences in productivity.
In school I was drastically more productive than my peers. In my final course where we made a 3D game, I relied on some asian kid with aspergers who was drastically more productive than me. Seems like if there's two instances of drastically than the distance between my peers and the asian kid is probably easily 10x.
[+] [-] seanhunter|6 years ago|reply
At one of my employers we had a very large and highly skilled dev community and being quant-biased, we tracked code checkins over time, number of tests written, number of pushes to production etc. I was very proud to be about number 3 or 4 out of about 1000 devs on these productivity metrics consistently over a period of 8 years there.
There was one guy however who literally dominated. Not only was he number 1 on any metric, but he did more checkins than the number 2, 3 and 4 devs combined. He had so many checkins that eventually our glimpse code search index whitelisted his userid because it thought it was a keyword in the language.
And it wasn't that he was a cowboy, he was obsessive about code quality, fixing bugs etc and also was top if you looked at test coverage etc. He was just a flat out machine - every day he would just come in and code all day whereas I have spurts of productivity with downtime etc. He didn't seem to need to be intellectually fascinated by a project and was just as productive at the beginning as at the end of a project - one of my colleagues joked that this guy's interest level in any project was always 83% ("Almost but not quite very interested") no matter what it was. He was very skilled and just churned out massive amounts of code all day every day. He never fell into the classic engineer's trap of overcomplicating things - in fact a lot of what he wrote was very simple when you looked at it (and I think that's part of what made him so good - he had a brilliance for finding really obvious, simple ways of solving hard problems) and because he wrote tests for everything he didn't really need to go back and or refactor things much.
[+] [-] EdwardDiego|6 years ago|reply
Why are those objectively useful metrics for productivity though? I can think of a dozen reasons why they aren't, as opposed to why they might be. Which, I guess, makes their objective usefulness subjective.
Some people will be working on longer lived feature branches because they're more complex, so they end up with one merge to master in the time it took the dev updating REST APIs to accommodate a new optional parameter to merge four branches.
Someone writes four tests that another dev might cover in one because the four assertions were all closely related to the same invariants and code paths. Who was actually more productive?
One developer pushes to production three times in one day because they typoed a property name twice... ...etc. etc. ad nauseum.
If you seriously believe that these metrics are objective methods of measuring developer productivity, I strongly suggest you spin off a business, because you're about to make millions.
[+] [-] WalterBright|6 years ago|reply
Genius is when you write a piece of code that's so simple everyone else thinks they could have done it. And yet they didn't.
[+] [-] onion2k|6 years ago|reply
And then there were the other devs peer reviewing his code, happily accepting his PRs without needing to add comments or request changes.
And then there was the QA team doing the integration and end-to-end tests, user testing, training, etc.
He couldn't have been quite so productive without those all those people.
That's not to put his amazing work down. No doubt he was brilliant. It's just that we shouldn't ignore the efforts of the people who enable developers like him to get on with what they're good at. Development is a team sport.
[+] [-] asjw|6 years ago|reply
Used to be like that when I was young
I also know that there's the guy that never writes tests, is incapable of writing non reduntant-code, pushes everything to master as a blob of unrelated changes, using git as the backup server, comments are sparse and mostly useless, code is a mess and 'deploy to production' means starting a Jupiter notebook on the Dev machine.
The same guy saves to the company millions in expenses and gets the promotion.
10-20-100x Devs are just very good Devs, nothing that automatically changes the fate of a company
You can have the best guitar player in the World and your band goes nowhere or you could be the Ramones...
[+] [-] splittingTimes|6 years ago|reply
Did that not lead to a super competitive workplace? I cannot imagine that this was very motivating to the remaining 990 devs... Or was it?
[+] [-] blub|6 years ago|reply
[+] [-] acroback|6 years ago|reply
[+] [-] thdespou|6 years ago|reply
[+] [-] lordnacho|6 years ago|reply
- Understood the requirements. Not just in a specific way, but also by having enough context to know what's likely to come ahead.
- Already have the tools familiarised. So the right languages are in their brain-cache, the CI/CD is familiar, and there's little need to read up on any new frameworks.
- Have already done something similar in the past. I work in the financial space, and the sheer number of wheel reinventions is mind boggling. Feed handlers, orderbooks, decision logic, aggregators, wire protocols. Someone who's been through the grinder a couple of times will know what the fixed points are and what you can change.
All of these point towards experience not simply in time but also in terms of projects done.
I've also come across a handful of people who were inexperienced but thought they could solve all the same problems without the benefit of having seen how others have done it, and it's been a disaster each time. Sometimes these people are hailed as heroes, because management thinks it's somehow to their credit that their Rube Goldberg machine seems to work.
The one or two really good junior staff who "get it" have tended to be the humble personality type. They don't bite off more than they can chew, but they eventually eat the whole cake.
[+] [-] 1-KB-OK|6 years ago|reply
I wouldn't call myself a 10x dev but at my last startup I was very productive, definitely more than expected at my skill level, because early on I had a lot of access to the people who designed our (undocumented, untested, and buggy) backend system. Then when I got a feature ticket (consisting of 3 words) I was able to quickly bang it out and deliver it, whereas other more senior engineers struggled because they didn't fully understand how the backend microservices actually worked and talked to each other.
Now I work at a big tech co and I'm in the latter position: I have a hard time understanding our complex CI/CD, and don't have nearly as much understanding of all the existing components. As a result I'm not nearly as productive and back to feeling like a 1x or 0.1x dev.
[+] [-] segmondy|6 years ago|reply
What I have seen with such developers is that they can jump into a system they have no idea about and ramp up faster than most people. I don't believe that everyone can be a 10x, I also don't believe that everyone that can be a 10x is even going to reach that field. From what I have seen, these folks are the sorts that enjoy working on non user centric app. They hate those ambiguities, so you might find them in security, or working on compilers, networking and lower level sort of codes where it's possible to conquer whatever demon that will arise from the code. It's almost impossible to WIN in user centric app where what's correct is subjective.
[+] [-] PopeDotNinja|6 years ago|reply
[+] [-] pkolaczk|6 years ago|reply
In a company I worked for, there were two teams working on the same product: the mobile frontend team and the backend team. The productivity of all developers was very similar, and both teams seemed to be working in lockstep and features were delivered mostly timely without big issues. Until the moment the frontend team hit a serious bug affecting the core functionality. After they struggled with it for a week, a senior Java developer moved from the backend to help them. He nailed down the bug in a day... in third party C code. This is why you need 10x devs, but they may not be immediately visible. A 10x developer is not 10x more productive. A 10x developer can solve 10x harder tasks when 1x developers fail to find answers in stack overflow.
[+] [-] jffhn|6 years ago|reply
Tried to come up with the draft of an equation (upgrades welcome ;):
cDev = capability(dev); // > 0
dTask = difficulty(task); // > 0
ssttTask = shortestSolutionTypingTime(task); // > 0
pk = priorKnowledge(dev,task); // in [0,1]
lcd = log(cDev / dTask);
timeTaken(dev,task) = (cDev <= dTask) ? +Infinity : ssttTask * ((1 - pk + lcd) / lcd);
productivity(dev,task) = ssttTask / timeTaken(dev,task) = (cDev <= dTask) ? 0.0 : lcd / (1 - pk + lcd); // in [0,1]
[+] [-] jknoepfler|6 years ago|reply
Something this article just can't capture is that many devs add net negative value by being allowed to work in an organization. They create complexity, chaos, and confusion. They might be smart, they might be dumb - the problem is that they have no clue what they're doing within a software organization, and often they don't care. They ship broken code, awful bugs, badly designed systems. They make bad technology choices. They don't measure their work (metrics, logs). They put no thought into anything other than manual W.O.M.B deployments. etc, etc.
It's very hard to not be 10x more effective than a net-negative dev. And then beyond that there are very good engineers who we typically put on the senior -> principal track who are able to get a lot done across a large organization, and generally create a culture and an economy within a company that is conducive to sustainable engineering. I expect the average principal engineer to be slightly slower than a college student on an algorithms problem (depending on the problem). I don't expect a college student to be able to drive cross-organizational software initiatives in a large company. I also don't expect that of most Senior engineers, and I don't think most Senior engineers I've met are even willing or capable of doing that.
I'm not sure I'd trust one dude's college experiment to be relevant in this domain.
[+] [-] dnautics|6 years ago|reply
[+] [-] dominotw|6 years ago|reply
Yea lots of junior programmers 'design for future' and 'follow best practices'.
[+] [-] netsectoday|6 years ago|reply
[+] [-] jvanderbot|6 years ago|reply
[+] [-] itsdrewmiller|6 years ago|reply
[+] [-] dvh|6 years ago|reply
[+] [-] onion2k|6 years ago|reply
[+] [-] nanonan|6 years ago|reply
[+] [-] overgard|6 years ago|reply
I think being a 10x developer is about getting from point A to point B ten times more efficiently. Its not just speed, its reduced waste and smarter planning. To do that, it's not just about coding, it's about deep understanding of the problem at hand. A great developer will be able to recognise things that are superfluous, find shortcuts, know when not to write something, etc. Its not just about coding faster, its about finding the shortest path. So they'll get you to having a completed work item 10x faster, but often by doing it in a way that might not be obvious from the outset to others.
But if you're working in the standard model where a PM is micromanaging... sorry "grooming" tasks.. then you frequently wont get that sort of performance because the developer doesn't have the autonomy. Without autonomy you lose what makes good developers good.
Of course just giving developers more autonomy isn't a panacea, most cant use it, but I think putting people into Scrum situations precludes most "10x" developers from being able to shine.
[+] [-] MichaelRazum|6 years ago|reply
[+] [-] sakoht|6 years ago|reply
I wonder if this study looked at a lot of programmers who just fix bugs or add well-defined features to apps, or really distinguish between those people and people who can build shippable products from ideas.
[+] [-] zeroonetwothree|6 years ago|reply
[+] [-] mordymoop|6 years ago|reply
[+] [-] WalterBright|6 years ago|reply
For example, not having an overflow bug can save your company $millions. Or avoiding a deadlock. Or speeding up your datacenter software by 1%. Or picking the right architecture at the beginning.
[+] [-] cryptica|6 years ago|reply
If you asked me to work on an existing spaghetti code project or on a very simple front end project, you wouldn't be able to see any difference at all between my old self and new self. In fact, my new self might underperform because I would be bored and going at a very slow pace.
There are 10x and 100x developer but you only notice them when the problem is very complex and you give them the opportunity to lead. The idea that 10x devs don't exist is self-fulfilling in a way because managers who believe that don't look out for these devs within their own organizations, so they don't promote the right technical people and they never get to see that 10x return.
I find it deeply disturbing that many people have no trouble believing that some CEOs are 100x more productive than others but they don't believe the same is possible for developers despite the fact that many software projects are in fact highly complex systems; in the same way that companies are highly complex systems.
[+] [-] js8|6 years ago|reply
If you control for this autonomy, by assigning them small "routine" tasks, then of course the effect is lost.
The paper somewhat advocates an approach to SW development that can easily result in this. If you give people lot of small tasks to be done, they will never be able to articulate that they are actually all very similar and can be factored out into an abstraction.
[+] [-] acqq|6 years ago|reply
I however suspect that such an organization, happy to meter the development, would not meter the efficiency of the whole, and especially would not allow comparing that whole to some other organizing model -- it could prove that the managers are the weak point after all.
[+] [-] BigJono|6 years ago|reply
Most businesses don't have access to top talent and they know it. Most businesses are specifically trying to create an environment where devs are interchangeable, and optimising their processes for the 50th percentile dev (if that).
If you do your measurements within that context then of course 10xers don't exist. But when it's John Carmack vs Scrum Legend #34598295 1v1 on Final Destintation with No Items, I know who I'm betting the house on.
[+] [-] zeroonetwothree|6 years ago|reply
[+] [-] jvanderbot|6 years ago|reply
They found that 95% of programmers had such high variance in their day-to-day that Bob on Monday might be >10x with respect to Bob on Tuesday. And, this variance dwarfed the variance between Bob and Alice, one of whom may be a supposed 10x programmer.
[+] [-] fxtentacle|6 years ago|reply
I would assume that people who are extraordinary good at their job will resist taking a course geared towards beginners, so they wouldn't be counted for this study.
[+] [-] preommr|6 years ago|reply
> There just aren't that many "best performers" available.
> The real world, of course, is far more complex than the limited, controlled study that we conducted.
I think this pretty much sums up why I don't like this article.
They had some real world-data, but didn't really have any interesting conclusions. Obviously someone isn't going to be good at everything, and if they were, there aren't going to be that many people. The issue of individual programmer productivity is very complex, and studies like these are way too abstract to draw any meaningful conclusions.
This is one of those cases where it's easier to talk about things using common sense because it involves things that are easy to break down by the human mind but hard to break down into a scientific theory. We know certain people are better at their jobs, maybe even 10x the average programmer for specific situations. But at the same time, it might just be that the comparison being made is unfair, or the person is good at one specific thing but bad at something else, these are things that have to be evaluated on a case-by-case basis.
People have gotten way too obsessed with the term as as a concept and it doesn't help to talk about 10xers because the discussion is at a high enough level that it's too vague and meaningless. It always just devolves into what even is a 10xer and what if someone is 0.1xer and so on...
[+] [-] AlexCoventry|6 years ago|reply
[+] [-] hyperpallium|6 years ago|reply
If it's only because you know the "trick", you still get 10x gains.
[+] [-] bobm_kite9|6 years ago|reply
Knowing the way is 10x over finding the way.
But I think this is still an interesting piece of research, backing up a lot of what we expect empirically.
[+] [-] jariel|6 years ago|reply
What?
While the data points are nice - I think the author has completely misunderstood the issue here.
I don't think in any given group of young devs there's going to be someone '10x better' than the rest, and this was never want '10x' was meant to refer to.
Though I don't really believe true 10x-ers exist, I have no doubt that senior, competent, experienced, creative and focused engineers who know how to communicate and collaborate are often worth 10x relative to many of their peers.
Particularly in tricky domains, in funky languages that have a lot of room for self immolation, doing non-standard things, a fully competent senior dev who has 'done most of it before' can basically ignore most of the pitfalls, knows most of the little idioms, and can get to solving the problem in a reasonable way, whereas it may take quite a long time for a lesser, junior dev, and may be entirely above the head of others.
[+] [-] hnuser123456|6 years ago|reply
[+] [-] bhk|6 years ago|reply
[+] [-] clarry|6 years ago|reply
John Carmack was in his early 20s when Wolf3D and Doom happened. Mid 20s for Quake. I have reason to believe he was vastly more productive than most developers his age. I don't think it's unreasonable to think there are other young developers who are similarly much more productive than the average.
10x or not, I do believe in significant differences in productivity.
[+] [-] Madmallard|6 years ago|reply