The 10x developer is not a myth (2013)
ybrikman.com
ybrikman.com
Especially if you're working in a small company, you're going to hit a point when there is a massive wall of work to be done, bigger than you would ever be able to handle alone, and your organization will fail if you don't do it. The skills you need to actually handle that situation are going to be more in the vein of basic professionalism than technical talent. Better programmers might need a bigger wall before things get rough, but they will still hit it.
The reason for criticizing the 10x idea isn't that it doesn't exist, the reason is because feeds into myths that might end up being harmful far beyond the actionable decisions it lets you make.
This is my core complaint. All software development is (eventually) rate-limited somewhere other than developer brilliance. Most business software hits this limit fast.
A huge portion of business software is stuff you can't solve with brilliance - tasks from integrating with other companies to building out simple new features happen at the speed of spec development, email responses, or other non-development limits.
If the 10x myth makes employers expect 10x productivity from certain devs, or even 5x, it's badly misleading them. Not always, there are compiler companies and ML firms and whatever else that need brilliance, but I think most companies that advertiser for 10x developers are usually limited by forces 10x development can't help with.
I've worked on plenty of projects where two smart developers would have massively outperformed the 10-12 mediocre and highly risk-averse developers working on the shitty (gradually getting shittier) code base over a period of 6 months.
For greenfield I don't think 10x productivity is likely though. If you're testing an idea you might throw away, cheap and cheerful will do.
If a business hires me thinking I am a 10x-er they have high hopes that I can't satisfy for their dimension of X.
There are good programmers, great programmers and dangerous programmers. But that's all relative to what work needs to be done.
If so how do we address such a problem?
I consider myself to be a 10x developer, but I'm not 10x all of the time for all tasks. Things that set me apart are the quality of my code vs other developer's code for a given amount of development time, the higher probability of my code being bug-free or nearly so before I've even run it, my skill at tackling extensive refactoring tasks with zero change in code behavior without needing to write and constantly run tests, etc. These skills all come from long-term experience, wide variety, and a fearlessness and belief that no development task is beyond my capability.
If you look at athletes, you'll see some that are really good at one particular sport, some that are naturals at pretty much anything they try, some that enjoy sports but aren't particularly good at it, and some (like me) that are so non-athletic that it's embarrassing. I think development skills are like that too. We can't really identify what '10x' means, because it depends on context and isn't tied to specific skills or behaviors.
This is a valuable point; many of the most productive people I know are breadth first not depth first. Being able to glue disparate systems together without having to stop and iterate with someone else saves a ton of time.
> Things that set me apart are... the higher probability of my code being bug-free or nearly so before I've even run it
I totally applaud your self confidence, and kudos if you're writing big chunks of nearly bug-free software before ever running it. My personal experience has been that even when I've been at my most productive, is that the probability of code of any nontrivial size being anywhere near bug free before running it is exactly zero. I'm scared of people who believe otherwise (I've never met someone who could prove it), and much of the success and productivity I've enjoyed in my code and management career have rested on the strategies to avoid assuming that code is nearly bug free.
The very best programmers and the very smartest people I know are people that came to the same conclusion - that every line of code is another bug - and then used that information to decide and inform how they're going to write software. They consciously avoid using fancy language features or playing code golf, they refactor often when architecture gets crusty, they spend a lot of time making sure other people can read their code, and they test and test and test.
I'll admit that's sort of a technicality, though. I've been programming for a long time, most of my career without anything more sophisticated than a text editor. I've taught myself to be pretty good at running code in my head, even fairly complex code. So what I'm really doing while I'm writing code is running it in my head as I write it, and finding the unhandled edge cases and other bugs while I'm doing it. I'm also compiling the code (if applicable) which finds other bugs. So, by the time I run the code for real, most of the bugs are gone. This is all a natural part of the act of coding for me, so I see it as coding rather than running/debugging. (I often debug in my head too; handy when you know roughly where a problem is but can't reproduce it.)
I agree completely with your last paragraph; that all helps to be able to hold the execution state in your mind while you're reading through the code.
In the past six years, I only worked on one project that justified an extensive test suite. It was a scheduling system for a large machine shop, which allocated multi-step manufacturing tasks across a suite of metal-working machines for dozens of concurrent jobs, while taking into account available machinists, working hours, breaks, vacations, and scheduled maintenance downtimes for each machine. Testing the algorithms for that required setting up a variety of consistent starting conditions, running the scheduler, injecting changes to existing jobs and inserting new jobs at certain times, and making sure that the resulting scheduling decisions were acceptable to the experts who'd been doing the schedules manually and to the machinists.
All of the negatives are: You get significant Lake Wobegon, and a ton of people think they are 10x that aren't (including a significant portion of people on this very website). People attempt to measure their 10xness in comparison to the worst engineer they know or work with (which is really likely comparing a 2x engineer to a 0.2 engineer). We have no way of evaluating it. No good way of hiring for it. The majority of actual 10x engineers don't get paid like it (they're just known as that really good engineer on the team / company). People spend time writing about it, and reading about it to no real benefit.
It really is the ultimate programmer insecurity. If Cosmo made a magazine for programmers it would likely be their splashy headline every other week.
The reason I mention it, is that it's wasted effort even thinking about it. If you're an engineer, figure out what you can do to improve your skills. Some things are flashy, some things are mundane. If you're hiring engineers, figure out what you can do to improve your hiring accuracy.
I posit (with no proof) that nothing useful has come from the 10x programmer discussions beyond the 6 months following its introduction.
The 10x developer existing means that the field is not really competitive yet and/or there is mismatch between who is trying to work there and what the actual needed aptitude is. Well managed company should facilitter knowledge transfer between people and competitive field should have large enough supply of people (unless the hiring process sux for some reason).
What a wonderful observation. This is true in fields other than software development, too.
An example: I use TensorFlow, but looking at the concept and implementation, I don't think I could conceive of and write TensorFlow in 10 years of work.
And this is exactly why software is eating the world. Once written it stays written and all those people that could not write something like TensorFlow if their life depended on it are able to use it as if they could.
Abstraction is a super powerful thing, all this building on the knowledge and capability of those that came before is what makes the whole thing possible in the first place. Probably the people that wrote TensorFlow would not be able to design (each of them individually) the computers that it runs on, or the operating system that allows them to run TensorFlow in the first place.
With e.g. metalworking, you can transfer the knowledge but training takes time. And building a new implementation of that knowledge takes time too.
But in software the knowledge and implementation is transferred effectively instantly. You can nab software off the internet (transfer knowledge) and start running it locally right now (implementation).
Software changes the complexity from O(2^N / T) to O(2^N).
The hammer, fertilizer and the metal press are all part of our tool-making culture, ways to adopt nature to do our bidding and in the case of the hammer and the metal press to shape it by brute force. In contrast, something like TensorFlow is a tool of the mind which means you can encode it as bits and those will travel the world a lot faster than your average bulk goods or container ship every will.
So they are comparable at some level and totally incomparable at others.
You aren't, generally, going to hire a Picasso. Picasso will be off being Picasso.
You also aren't going to hire Greg, the guy who took one art class in middle school who just decided last month that he's going to be a artist.
What we are really talking about is the 'artist of the line'. Accessible professionals. Yes, there is still a spectrum there but it is more in the 10x territory. And some are 10x for very particular work and some for others.
What gets me with the whole 10x thing is the idea that a 10x developer in one particular circumstance can be dropped in another and be expected to perform at that same level. That's not how it works.
And I don't just mean on the scale of a day (we've all had those) - there's a reason FizzBuzz was a thing; there are people with no practical coding ability nonetheless interviewing for engineering jobs. Somewhere, one of them got hired. Somewhere, they were able to BS - or download already prepared software that did what they were supposed to code - and keep that job.
Don't understimate the human ability to learn. 10 years are plenty of time to learn the math and to find good code structures.
Google was using for years a tool for deep belief networks, then suddenly deep learning was a thing and they started TensorFlow based on what they learn of the deep belief networks tool. So you can track the origins of TensorFlow to 2010 or before, and for sure it wasn't developed for 1 person. It could start as a 5 person project and now probably it is more than a hundred (aiming very low). If you add on top of it all the research done where they have been collecting ideas, then you realize the amount of knowledge behind TensorFlow is huge. And the amount of people and time under it is also huge. Probably no one can understand it completely, even if he/she spend 10 years.
The downward range goes very, very deep. And that's of people that actually do end up shipping something that "works", somehow.
I've personally rewritten an app in less than a week that had two devs on it for over 6 months. Their deliverable didn't really work at all, even after the 1+ minute loading time (Win32 app).
To be fair, a lot of that six months was probably just nailing down the requirements. Your rewrite enjoyed having that design work already done.
I'd argue that building applications is 90% design, 10% code. The code part can balloon to a greater fraction if the developers are not competent enough of course.
Given how many clients that company had, the main conclusion I draw is that as an industry focusing on helping the .1x people improve is more likely to make a noticeable difference than chasing the other end of the spectrum.
The lack of true apprenticeship, fellowship, mentorship is an incredible disservice to our industry. The number of people who all need to rediscover the same lessons the hard way wastes so much programmer capital.
Do you think that's possible? More often than not the .1x people don't seem to care either.
You're comparing a single person to a whole community of PhD's. Getting up to speed enough to be a useful member of such a community is more doable.
And in general, what one fool can do, another can.
The article is strangely defensive of the number 10 specifically; having discussed this topic here several times I get the feeling most people on HN already agree that there are order of magnitude fluctuations in productivity from person to person at any given time, but that 10 itself is a biblical number -- symbolic and not even meant to be taken literally.
I'm sure 10x has been true somewhere for someone, but there's nothing special -- nor empirical -- about the number 10. There are more people 2x better than average than 10x. The distribution looks like what you'd expect -- peaks at 1 and falls off in either direction.
> You become a 10x programmer not by doing an order of magnitude more work, but by making better decisions an order of magnitude more often.
I think this isn't necessary to be 10x more productive. You can make a single decision and become more productive. You can also use a single philosophy. You can also get yourself in the right company and on the right team surrounded by people who are smart and cooperative instead of competitive, and watch everyone's productivity soar.
The most 10x-famous programmers I know are ruthless about not implementing things until they need them so badly it hurts. And they keep their code really, really, really simple. No cleverness, no tricky bullshit, just super-simple super-readable easy to understand, and literally boring code.
Whatever the case, these people are always outliers. Unfortunately that doesn't prevent teams from claiming that they only hire 10x's.
No one starts out as a 10x. Perhaps instead of focusing on who is or is not 10x or how many 10x's are out there, it is more interesting to explore HOW people BECOME 10x?
A more realistic view is that individuals are a moving target. Skill is something that needs to be nurtured, practiced and modeled by mentors in order for others to pick it up. Orgs that just stop at the fact that people are going to have a wide distribution of skills are doing a disservice to themselves and their employees.
I thought the perceived idea about the 10x developer was that he/she is 10x better than the average programmer, not the worst.
So even this scientific study (from the 60s) says that there aren't 10x developers according to this definition: the ratio goes down to sqrt(20), using the geometric mean, if a good-enough sample was chosen. Program size and program execution speed would put that ratio to sqrt(5) and sqrt(10), respectively.
That could well be what people perceive. It's not what the studies said. While the article has some good references, I might as well quote Peopleware again just for the fun of it. I churn this out every so often:
A 2nd edition of Peopleware summarises it; the 10x programmer is not a myth, but it's comparing the best to the worst; NOT best to median. It's also not about programming specifically; it's simply a common distribution in many metrics of performance.
The rule of thumb Peopleware states is that you can rely on the best outperforming the worst by a factor of 10, and you can rely on the best outperforming the median by a factor of 2.5. This of course indicates that a median developer, middle of the pack, is a 4x developer. Obviously, this is a statistical rule, and if you've got a tiny sample size or some kind of singular outlier or other such; well, we're all adults and we understand how statistics and distributions work.
Peopleware uses Boehn (1981), Sackman (1968), Augustine (1979) and Lawrence (1981) as its sources. [ "Peopleware", DeMarco and Lister, 1987, p45 ]
Further author even punts at the end of article by claiming that its not needed to measure difficult to measure things as we can instead reason our way to the right answer which is practically nonsensical. Measuring is step one in actually reasoning about things.
In short author may be a good developer but he is certainly not a 10x author.
This is roughly what I estimate the productivity improvement a good developer gets when they're working on a task that fascinates them and that they choose for themselves, and without too many dependencies on productivity killing things (like builds and flaky external libraries and services).
The most productive people I knew tended to the people who didn't do as they were told. They were amazingly productive at producing the things that fascinated them, much less productive at the drudge that the organisation demanded of them. Sometimes the organisation was able to recognise that they were doing useful stuff (despite the fact that they weren't always pulling their weight on the things they were supposed to be doing) and they became rockstars, sometimes it wasn't and they became pariahs.
Also, sample size would matter. Assume that there really is a Superwally out there who has worked in programming for seven years for some company without accomplishing anything at all. And I imagine that there is. It would matter a lot if he is part of the sample. In fact, the only sample that would make sense would be all programmers in the world, and now, thanks to Superwally, we all look pretty good.
And of course, there is probably some Hyperwally as well who can smugly boast seven years of negative productivity. Deleting random stuff, breaking functionality, leaving messy code for others to untangle. Adding Hyperwally to the equation and the relative productivity of everyone else would approach singularity levels.
Anyway, in the 60s the profession was in its infancy, so I'm not sure how much studies from this era matter today.
I bet you'd surely find 10 to 1 or 100 to 1 differences in programming productivity on a project like that following waterfall methodology in the 1960's.
I think Fred Brooks was right to argue[1] that we're not going to see dramatic further improvements because we're at the point of diminishing returns on overhead and most of the remaining work is actually inherent to whatever problem is being solved. The closest we've probably come to a change on that scale was the rise of cloud technology shrinking the feedback cycle for testing but I don't think that's been an order-of-magnitude change for most people.
(yes, this was my first project out of uni. A can-do impossible-is-nothing attitude can be misinterpreted to lead you to relentlessly pushing against a wall rather than resourcefully going around it.)
Now, I've seen 10x quality, though sometimes they're a little slower, but never 10x slower. So maybe 1.2x to 3x times slower for something on the order of 5x to 20x quality.
That higher quality might pay off long term for the buisness in hard to measure ways, such as faster future extenssion, better customer experience, less work required on bug fixing, etc. If that's what people mean by 10x, I agree, they definitly exist, in fact, compared to the worst there's probably infinite x as people are saying, some programmers can't ever get certain things to work at all.
P.S.: Actually, I've seen maybe 2x or 3x productivity on teams with uneven standards, generally lacking code reviews. In those cases though, the 2x or 3x productivity programmers always had similarly lower quality code.
The norm used to be that you do module you are responsible for - meaning you can work for few weeks on something biget and alone. At that scope, bad programmer might end up doing mess that is very difficult to finish. If the company does testing and returns bugs to original developer, the developer will be significantly slower.
No, the guy would be doing the entire project.
I've worked with "10x" programmers before, exactly one to be exact. The sort of guy who would code to an obviously-wrong spec just to annoy you as a manager, but have the "correct" implementation done and waiting to commit the second you'd amend it. It was an interesting time, and we got a lot done very rapidly. If I had talked about scrum or anything like that'd he'd take one of the other 50 job offers he could get within 24 hours making double - he worked with me because I made his life as easy as possible while trying to give him interesting work.
Of course it's not sustainable business-wise for a myriad of reasons. You can't staff a team with those people, but man was he nice to have as programmer #1 in a startup.
I always thought of 10x as a qualitative description, not quantitative. There are certain inflection points where the wrong decision can cause a 10x amount of time to be wasted. One person might have the correct (but counter-intuitive) insight about whether building vs. buying is the right move for a given project. (For example.) Everyone else on the team disagrees and goes with the more obvious choice, which becomes a disaster of a project.
So I see 10x as more about wisdom and strategy, not doing 10x the work. It's not always such an large and obvious inflection point, it can be a single algorithm that can be done simply with little code or in just the opposite way. The right approach can reduce the complexity and code by 10x over time as the bugs go down, the maintenance goes down, etc.
These things add up, and over time a project under one person's leadership can easily end up with 10x the complexity, bugs, etc. for needless reasons that someone else might have avoided.
I have no doubt that the gap in value from the best developer to the average (let alone the worst) can span 10x over time.
I've been on both sides of the 10x divide (i.e., the 1x working with a 10x, the 10x working with a 1x). To be clear, these productivity levels were relative to the project, understanding of the project, and the point in the project's lifecycle. There's native talent, but context is just as important.
It's not really sustainable to have that productivity difference unless you have a team structure to support it and bring people up – and sometimes I wonder if the team structure is more emotional cover than an actual aggregate productivity boost. It's not sustainable because the 1x developer can't handle the 10x developer's velocity of change. If you are the 1x developer, just at the point when you think you've finally made a valuable improvement, the rug gets pulled out from underneath you yet again because of a change or fix made by someone else. It's demoralizing for everyone, and the 1x developer often becomes the 0x developer (I'm afraid this has also happened to me).
It's harder to find unsustainable states because they don't last for long (team breaks up, everyone becomes demoralized, people drift off, etc), which is part of why I think 10x productivity is sometimes treated as a myth.
The result is more likely a conswquence of missing communication about changes being done and badly split tasks/responsibilities. Good senior developer should know not to pull rugs from junior. He should not be rewriting juniors work that often.
I mean seriously, demotivation happening this way means that the 10x dude should not work in team at all - he should have work individually.
A common situation, for example – some small bug is assigned to a less productive member of the team. The fast developer has to touch that area of the code for some other (often more critical) change. The fast developer sees the bug and just fixes it, or perhaps invalidates the need for that bug fix. Now the less productive member has their work undone. Claiming territory would slow down the fast developer, and also is demotivating for people who are motivated by increased code and product quality and want to bring that attitude to every bit of code they touch. You can run a smallish team with widespread improvements if you are in a situation where turnaround is fast. We're not going to run into too many conflicts if each of us finish our work and get it merged on a daily basis. But then you have that one person who takes a week on a change, and it doesn't go so well. Unless you put them in some codebase ghetto, where changes won't conflict because no one actually cares about the output.
How do you manage multiple kinds of vehicles on the road? Speed limits? Minimum speeds? Passing lanes? Semaphores? There's no one right answer, and all the answers are wrong from some perspective.
Of course they exist. We're talking about a talent distribution here and there will be actual human beings who live in the 90th+ percentile who are demonstrably more productive, probably more than "10x", than those in the lower half.
The thing about the 10x claim is that it takes something complex and creative and applies a scalar multiplier to it.
Talking about 10x programmers is _semantically_ problematic.
It's telling that there's no such thing as industry talent matrix. Instead of general skills - creativity, accuracy, speed, debugging insight, ability to learn new languages/frameworks, team leadership, good-to-have-around vs toxic asshole, and so on - we have this myth of "the rockstar".
A certain kind of management loves because rockstars because having them around reflects well on management (reason number one for hiring them) and supposedly they are super-productive (reason number two, which often turns out not to be true in practice, especially in a team setting.)
The hiring process tests for almost none of the qualities on the talent matrix. There's a ridiculous notion that knowing algos makes you a developer worth talking to, and a slightly less ridiculous notion that a bit of hazing tells you something about how well someone works under pressure.
The bottom line: that after all these decades we have far too little research defining the qualities that really matter in different work contexts, and almost no research at all into how to select for them.
I'm not a 10x person, but I have worked with some. I don't think they are unique to programming..there are 10x folks in every field.
Sometimes you don't need a 10x person, and if you don't, it can seem like they don't matter. In those cases, a few 1x people will do just as well. But I do believe that sometimes you _do_ need a 10x person, and if you do, you can't do the same things without them. In those cases, I'd absolutely take a 'toxic' 10x person over the nice-but-1x alternative.
Part of the issue is that there's more work for programmers than ever, and most of that work is of the 1x variety.....if you're just banging out CSS for some small-business website, it doesn't matter whether you have Jeff Dean do it, or a new grad from Omaha Community college. If, however, you need to write a new globally consistent database abstraction at scale, then the new grad probably won't cut it. If you actually need that thing, then it wouldn't matter if the new grad was the nicest person on earth, and Jeff Dean the most 'toxic' (though actually I understand that he's a very nice person).
Do people say "I'm a 10x programmer" and get promoted or some sort of perk? Get better jobs by saying that you're a rock star?
Of course not. The premise of 10x programmers, outside of bloviating bloggers, is primarily one that people observe in programming teams. The "go to" person, the person who invariably initiates all of the important shifts and base designs, etc. Many projects start around such a person, they leave and it slowly rusts under a team of normal competency developers, who eventually all disperse and join another project started by a standout developer.
My experience in this industry is that there are absolutely extreme exception developers, and thinking back I'd say it was about 1 out of every 100 developers in most orgs. They were the people who didn't need to be hand held, used heuristics to find solutions, developed designs that invariably became the kernel of solutions, etc. Other developers were critical in the mix, but the notion that all are the same is destructive and unrealistic.
Edit: grammar
The problem is that nobody defending it is specifying what measurement will yeld those orders of magnitude difference, and what is its relevance. Claiming a difference without telling in what dimension is an empty claim, and that is exactly the problem with the 10x developer idea.
(By the way, yes, there are plenty of problems nobody on Earth could ever solve. That doesn't follow from the fact that easier projects fail, but it's not false either.)
Nobody's said there aren't unsolvable problems, the question was whether nearly every massive failed software project (and they're common) represented such a thing - obviously no.
He cites this as evidence and still goes on to talk as if the observed 10x-ers were 10x average. Then he tries moving the goalpost, with talk of high-level project decisions and code not written. Just come out and say, "A true 10x programmer does X, Y, and Z. A true 10x programmer would never do A, B, and C." Sounds more like a certain fallacy involving Scotsman when phrased that way.
The only saving grace is that he backs off and recommends against a hiring strategy targeted solely at ninja rock-star devs, but then he reinforces the boogeyman of negative programmers
I get that some people are good. There's nothing outlandish about Peopleware's cited figure of 2.5x average programmers, but that's not so incredible that the 1x devs need be weeded out. There must also be a handful of developers with IQs of 160 walking around, but there's too much demand for talent to act as if such rarities are the baseline of who's employable. None of this is worth continuing to blog about.
The 10x developer may or may not be a myth, but the idea that you can design your system for exponential traffic increase without any tradeoffs is not engineering, it's fantasy. I guess "no silver bullet" is dead in the year 2017.
https://static.googleusercontent.com/media/research.google.c... (page 11)
Additionally, one thing the best programmers I know have all drilled into me is don't write code speculatively. You should write code because it solves the problem you have now, not the problem you think you're going to have in a couple years. It's very much a novice mistake (one that I've made a dozen or so times, sigh) to think that you can jump straight to your "ideal" architecture without any of the steps or missteps along the way.
It's very much a novice mistake (one that I've made a dozen or so times, sigh) to think that you can jump straight to your "ideal" architecture without any of the steps or missteps along the way.
Code evolves as the problem evolves and NEEDS to be adapted. Is impossible to foresee the future.
The key words are slightly. The trap is to overgeneralise or apply a technology or approach like a hammer without understanding its limitations.
Out is impossible to foresee the future, but trivially easy to see current requirement and extrapolate a bit.
I can't count the number of times I've "trivially extrapolated a bit", showed my boss or VP, and then gotten back "actually, we don't want to put any more effort into X. I appreciate how you went above-and-beyond, but priorities have changed, and it turns out we really want Y instead," followed by much handwringing when I go back to the code and find out that the flexibility and modularity that I built into the system expecting we'd do more of X next actually impedes progress in making it do Y.
Lest you think this is just bad management - I work for myself now, on a startup, and I have the same problem (or would had I not beaten this habit out of myself). Very often, I'll think "Woah, there's a much more elegant approach that will let me do Y and Z much better at relatively low engineering cost", and then I'll finish X, and put it in front of potential users, and they'll say "Actually, we don't care about Y and Z at all...why would we want them? We want to do A and B instead", where A and B take the product in a completely different direction from Y and Z.
There is a place for planning a little bit ahead, but that place is to plan to reach the next milestone as quickly as possible. You should never try to guess what the milestone beyond that is without checking in with users or management.
Without an established culture of adaptation and refactoring, your team lacks the perspective necessary to know what the 'right' architecture is.
The paradox here is that people who could extract the most benefit from a rewrite don't have to ask for one, and those least equipped to benefit constantly blame their problems on the lack of one.
At the end of the day, the rewrite or 'perfect architecture' is a dodge. You get to be left alone for 4-8 months with nobody hassling you, which means the perverse incentive is:
rewrite = peace and quietBut, I believe it does not really matter (at least most of the time, most meaning something like 99%).
We are working in teams, inside a company that has a certain culture, rules and processes. How we work together as a team and how the company/culture/system we work in helps us in / prevents us from doing our work has a much greater influence in overall results than individual programmer performance.
This also includes how the system supports us in learning (not only formal training, even though this might be beneficial) and teaching. Teaching each other skills needed for the job, and learning how to work together so that we amplify our collective skills and dampen our shortcomings.
Most just don't have the money, culture, management, fellow coworkers, or whatever else to keep that 10xer (often times even get them in an interview).
Seriously most companies can't even keep a 10xer janitor if they tried.
1) Oversimplification
2) Arguing over semantics
The term 10x engineer is particularly bad because it implies something: that some engineers are just generally 10 times more productive than others. I'm pretty sure most engineers would be vehemently opposed to their performance or value being quantified, so why do we even bother arguing about it?
If I remember right, this term was inspired by some study that showed that some students did their CS homework at a school (CMU?) 10x faster than other students, and the implication that some engineers are just that much better than others as to deserve distinction.
Anyway, this is obviously true. There are some things that simply can't be written or designed by the average coder (or teams of average coders, for that matter), say important bits of the Linux kernel, key optimizations for your latest AAA titles, hairy distributed protocols, etc. No amount of project management will turn a team of average coders into one able to produce such things. In these case, the exceptional coders are more like ∞x than 10x.
And in other cases, you might only see a marginal improvement in performance if at all. If the task is particularly dull, a previously ∞x coder might turn completely unproductive.
Can we just all agree the term is stupid, evokes a sort of reliance on metrics we all hate, that hiring a team is more complicated than assigning value to coders and maximizing, and just move on?
THe thing most people lack in all those examples is body of knowledge, not aptitude. All those areas are learnable by average developer.
But as I understand it, the "10x" means 10 times the productivity of an average programmer. I wonder how productive the average programmer is. I find this question super interesting.
For example, I see more and more programmers who use "Query Builders" and "ORM layers" without understanding the underlying database mechanics.
Coding this way not only takes multiple times longer then - for example - just writing plain SQL. It also often results in code that runs hundreds or thousands of times slower. And complexity explodes as the project grows.
I have the feeling that - with the rise of frameworks - this might be the new "average" of coding. If so, then there definitely are coders who are orders of magnitude more productive then this average.
It's easier to add a special case check, than to read through the codebase to see if it's even needed, or, God forbid, to refactor in 5 places so it's not needed (it might break sth else!!! I would have to read and keep in memory the whole control flow of the program!!).
Programmers have to do dozens such decisions every day, so after a few months if they go the easy way too often it adds up and creates chaos.
I've done this myself, and seen this done by younger programmers. It's that crucial skill of stepping a few steps back and looking at the code as a whole.
I've seen a great compact example recently, one of the students I supervised wrote sth like this:
List<Person> findBySurname(String surname) {
List<Person> persons = session.find(surname);
if (persons.size() == 0)
return null;
return persons;
}
...
List<Person> persons = findBySurname(surname);
for (p : persons) {
p.doSth();
}
:) this example is easy, but in more complex situations it's easy to do the same, and it adds up. This is one of the reasons I dislike OO programming (especially the kind where you hide everything behind a few layers of interconnected objects). Because it makes it harder to understand what REALLY happens on the data level.
My company is currently in the process of moving back to an ORM after 5 years or so abandoning ORM usage due to nightmarish performance using NHibernate in .Net (maybe more of an indictment on the code than anything else, but I don't know the specifics of the history). We found the company had a lot of problems that resulted from handwritten SQL, including lack of ability to adequately abstract the logic for proper unit/integrated testing, and inconsistent data fields being returned by various queries, resulting in inconsistent api endpoint data returned to the client and thus inability to safely abstract without significant hacks/nebulous data model state.
The worst thing we encountered with handrolled SQL over ORM was that it actually hindered our ability to deliver major business requirements. We had no ability to gate content by various values from other tables without modifying the handrolled SQL in every single location...not a good situation to be in at all.
You are coding against actual queries? Why not functions to hide the table abstractions:
https://www.postgresql.org/docs/current/static/sql-createfun...
https://dev.mysql.com/doc/refman/5.7/en/create-procedure.htm...
>We had no ability to gate content by various values from other tables without modifying the handrolled SQL in every single location
Again, don't sql functions solve this?
The impedance mismatch between relational and OO is much bigger.
Isn't that roughly what an ORM/ODM is?
I imagine the "10x developer" would just be really good at avoiding this kind of thing ... most of the time.
Would somebody then, instead, be able to become 10x more effective by thinking 10x more about their work, before they do it?
Note that I'm certainly not referring to myself here -- I consider myself Just Average. I'm thinking of friends and colleages I've known over the years who have this seemingly natural gift.
That being said, I also think everyone can benefit by finding some sweet spot between 'thinking hard up front' and 'analysis paralysis'. For me personally that means start by doing something, then revise and iterate. That's just my cognitive style I suppose.
The focus here is on entirely the wrong thing. It is the development environment provided by the company that enables above average developers to surge into hyper productivity. Good programming practices. Competently prepared requirements. A collegial atmosphere that encourages frank and open communication between departments.
Searching for 10X developers is like looking for a silver bullet. Silver bullets do exist in the real world but ask a shooter whether they provide results any better than the common kind of ammo. Mythical stories can be fun but in the real world we have real work to to, real problems to solve, and while you can find shortcuts generally you don't find them by looking from them. But dive into the messy chaos of creating order out of nothing, and from time to time you will come across real honest to goodness shortcut opportunities that may provide up to a 10X increase in productivity. Use them if you can, but don't waste a lot of energy in chasing them.
Also, the idea of a 10X rocket scientist is rather glamourous. But the fact is that there are real opportunities for productivity improvements that are in the boring details, slogging through improvements in processes, making small incremental improvements continuously and consistently. There is more to learn from refactoring than from chasing clouds.
True, an environment can encourage the laggards to catch up or fire 'em if they have no interest in improving their skills and knowledge; but it can't wave a wand and create the skills. I would also note that there are tenX (plus) refactorers who can freely cut large amounts of code from large projects without risk, too.
If you started tackling mathematical puzzles when you were eight, and programming a couple years later you're a different species than someone who switched majors to computing in third year for financial reasons; the early starter's brain is actually physically different (for instance some of your visual cortex and memory will now likely be devoted to math and logic instead of geography, this has been measured in chess players.) Same with a concert pianist vs someone who started playing the piano at age 20. Sure, the environment of the concert hall or practice hall matters - just not nearly that much.
I agree we do need to spend more time paying off boring technical debt, too; though that's not getting much more popular.
I don't want to leave the wrong impression. There's absolutely nothing wrong with doing a very conscientious job of coding and recoding that a whole lot of others could also do, just with a better ethic and constant attention to detail - we need many more such coders too, and I honor them very much.
How to be a 10x programmer: make 10 other 1x programmers into 2x programmers.
Yes, if you have a small team of say 10 people, a very competent lead engineer can make all the difference by setting up proper testing, SCM, CI, etc. i.e., by choosing the right tools and people for the job.
However, as soon as you have a slightly larger team, these decisions will usually not be made by one single person. If you have a large project with dozens or hundreds of engineers, you'll have dedicated teams for some of these tasks, making their own desicions.
In my opinion, the most important thing then is to spot anything that will make things go haywire, communicate them and convince the right people that this has to be fixed. If you force a new porgramming language onto the whole team because it makes you, the 10x engineer, more productive, you might face endless discussions, additional training costs and a big backlash ("why do we need this now?") from the team.
When I look at great developers, they can not only build things without taking as many dead ends but they can explain why and share their reasoning with the rest of the team effectively.
The very best can not only complete their own tasks well but their "prowess" (for lack of a better term) is witnessed and people seek out their advice.. therefore making others more effective too.
The (unsurprising, really) backlash was not because their work had slowed down (in fact it solved many problems) but because their non-work was impeded. Flash was a bit dodgy, so browser games were out. Their favorite torrent programs didn't work in Linux. Of course, they couldn't use these reasons when complaining to the boss, so there were some amusing verbal gymnastics....
Another interpretation of this is that 10x programmers get dragged down when they have to work on teams that are too large or don't grant autonomy.
Some people argue, essentially, "programming is complicated," but even if you want to claim that programming consists of multiple dimensions along which programmers can be measured, how about when one person outperforms another on every dimension by a factor of ten? What should we call that other than one person being ten times better than another?
Other people argue that while 10x developers may exist, teamwork matters far more. Well, what do you suppose would happen then if you managed to assemble a team of only 10x developers?
Some students certainly outperform others by a factor of ten. I'd hesitate to score managers numerically, but it seems plausible that working for one could feel ten times more smooth or whatever than working for another, whatever that means. Intuitively, probably not factory workers, but prove me wrong.
10x is not actually that much. I could play basketball with Michael Jordan or chess with Magnus Carlsen, and they'd win essentially an infinite number of games against me without losing once. That doesn't mean they're infinitely better, because theoretically I could through practice become as good as them, but the factor is way more than 10.
It is possible that those that assemble Ikea furniture for a living have 10x over a typical Ikea-buyer.
But in a professional setting I've yet to meet a single developer I would claim to 10x. Probably not even 5x. Unless one would look isolated at tasks that requires specialized or domain knowledge which the other person doesn't happen to have. And I'm pretty sure there would be tasks where same person would nX me.
Yes, you can deliver a project with the right person with 100th of the effort, but this is not repeatable (the person will move on or very likely work as singleton contractor). If you get a 10x developer at the rate of the 1x developer and can convince him to stay at this pay grade, then we would be having an actual topic to discuss.
There are reasons to think that productivity is multiplicative and not additive property, leading to log-normal distribution. Person who is hard-working × experience × motivation × single-mindedness × self-management skills × 2sigma IQ can get ahead of person who just has the smarts.
Prime example of '10x' programmer is Richard Stallman.
Extreme Pair Programming - Guy Steele and Richard Stallman http://cycle-gap.blogspot.se/2007/09/extreme-pair-programmin...
Also I love, love this line: "10 engineers writing the wrong code could definitely be out performed by a single engineer writing the right code."
Especially as it extends up the chain -- 10 employees building the right product can outperform 100 employees building the wrong product. Etc.
and
"From years of experience, a great programmer will know that errors are much more costly to fix later."
So which is it?
They did find a difference between a programmer with 7 years of experience and a programmer with no experience.
Programmers writing features that add points of failures to previously working systems
https://leanpub.com/leprechauns
I liked it
It all depends on the job to be done and being the right fit. But some people have this talent and skill to make the right decisions split second, over and over again.
I definitely prefer one 6x dev over 6 average developers that are creating a horrible spaghetti of bad ideas and poor decisions, not talking about all the meetings they need to align and try to fix the mess they continuously create themselves.
Doing good design and tooling upfront is at least a 10x opportunity. Too often I've seen it get brushed off by people who want to see quick results, to the detriment of the long-term design goals.
For example, I used to ask sysadmin/devops people what syslog was. One of six would not know, four of six would give a basic answer, one of six would give a more in-depth answer. Then I would ask what syslog's various facilities were and what the severity levels were. Only one of the six would give a good answer.
Actually, I program Android now, but knowing the order of severity is still useful as it is in the same order in the Log class (althouh they add one beyond DEBUG - VERBOSE).
Once I read an article about the top people at Google, and they claimed these people are three standard devíations above the mean. I noted that the author saw this in the same pattern I did.
What are the decision-making habits that make someone significantly more productive on a software engineering team?
What are ways to imbue a team with these habits?
Someday we'll have "problem-solving" classes in elementary schools to help teach those basics; and better unambiguous communication, etc. One habit that's been well-documented for a long while is that the best problem-solvers take more time being sure they've understood the problem correctly and settling on an optimal approach before charging in doing the work.
The best habits that often spring from good character - I agree with Bourne on that - those with neurotic motivations or insecurities may choose "solutions" that show off their ability with some extra arabesques, rather than taking a more straightforward path that's best for the company, for example. Not to mention being willing to possibly embarrass yourself by asking what may or may not be "dumb questions." That's huge.
Good fundamentals are also good, like being attentive to details and never letting crasher bugs remain unfixed.
I don't think you can imbue good habits on people who don't want to be imbued. So that's what you need to ensure first.
The main difference (besides using vim) of a 10x programmer, is being able to immediately envision 5 ways to solve the problem, mentally following that path and seeing the pros and cons of each.
The 10x programmer probably does really hard stuff on weekends for fun.
The 10x programmer doesn't give a shit about your paradigms if they don't make the code more maintainable.
The 10x programmer's code is fun to read.
The 10x programmer's code could be read by a non-programmer and they could understand the jist of it.
The 10x programmer can't tell you the 'most interesting bug' they've ever found. The solve bugs all the time. They solve them and move on, and remember the lesson, but not the bug.
The 10x programmer doesn't fit in well at the office and usually has to start his own business.
He also types fast.
Is a 10x programmer also a 10x businessman?
What if 'x' is transitive? Is the 10x programmer, 10x businessman 100x?
That might explain things. I've seen plenty of 0.5x programmers who are 20x bullshit artists.
I wonder because I feel that this is my situation. The people I started working with are so much above my skill level, it's ridiculous.
How much more experience do they have than you? Do you feel like you learn new things?
I've learned quit a lot in the former team, the new team on the other hand.. I've hardly coded anything this year. I work with code, but I don't build stuff. As a result, my coding skill progression stopped almost completely, while general IT skills improved somewhat. In my former job, I was able to work at my own pace and do everything by myself (SQL dev). I believe I was good there. But now? Working with big systems in Java developed by others in unknown frameworks, done by high skilled people.. I suck.
If the answer to any of the above is "yes", then you may just need to find another job that better suits your interests and needs in terms of career progression. Software development jobs can vary greatly in terms of being interesting/challenging. Being on a big development team is sometimes not the best option for developers that are just starting out. There's simply not enough room to grow and explore because your work environment is so rigid and pre-determined by others.
Incongruously, I think mostly about non coding related problems. Still, if I understand the code base and its frameworks, the degree of coding related thinking increases substantially.
But normally, I automatically think more about "How to improve the reviewing process? How to improve onboarding? How to calculate costs? How to organize / improve our customer support?" and similiar problems. Those topics are all more in the project manager department. Maybe I'm better suited for that kind of role, but I can't take myself seriously if I haven't build a strong tecnical skillset.
FWIW, those interests really should make you a good choice for moving into a less technical role. I don't know if there are career paths that don't start with being someone technical but that's something I would persue, if I were you.
Nor is there a way to quantify "good code" in any scientific manner. It IS possible to identify obviously bad code, BUT "good code" comes in a variety of forms and looks different depending on the experience level of the developer.
In the end, many of the measures that people apply to assess programmers are simply a matter of personal opinion.
edit: downvoters - if you think I'm wrong then please explain your counter opinion, don't just downvote. A downvote without a counter opinion simply confirms my assertion that there is no science to this because you won't identify what that science is, you have only a vague opinion that I am wrong.
Now have a blast whatabouting, caveating, and arguing definitions!
I don't think a lot of people with 10+ years of experience would say no ( if you do, it may be time to change company).
Compared to someone that can't code I'm infinitely faster in theory. Do note that in reality, if someone that can't code needs to write code, he'll likely learn to code first. However, once he learns to write code, he is no longer someone that can't write code.
The 10x programmer isn't 10 times nothing, of course. The 10 times rule is, I think, 10 times better than average. So we have to know the average first.
The amount of programmers rises very fast: IIRC, the amount of programmers doubles every 6 years or so. The average programmer therefore has 6 years experience.
The 10 times programmer has to be 10 times better than that. How is he 10 times better? He has to be able to beat a 10-person team of people with 6 years experience on average. That is a team of 4 juniors with 4 years experience, 3 "medium" programmers with 8 years experience and 2 senior programmers with 10 years of experience.
Imagine a contest where you have to develop a huge SAAS management-like system. One team has the 7 developers described above. The other team is the solo mythical 10 times developer.
Well, I think the 10 times developer is going to have a head start, but he's going to burn out within 2 months, releasing nothing and starting a new project somewhat later. The project manager now has to find a new 10 times developer, but he finds out that no-one can replace him and they need to start over.
Meanwhile, the 7 developers are playing table-tennis and having boring meetings and finish the product much later than planned, but it is done and it sells fine.
About your project, i had the experience of building the exact same project ( an product demo ios app with a web backend and its content management interface). First project had to be done using "enterprise" practices, and the other was free. First one i did with a senior developer helping me on the web interface side, the other with an intern i had to explain what MVC was.
First project took 6 months, plus 2 more because of some guidelines i didn't respect first, plus a whole team of admins to handle the production side. It probably costed more than 100k to the company ( not counting the internal days spent in meetings). The internal team that was supposed to maintain the code wasn't able to do so.
The other took less than 3 months and costed something like 10k, including server cost (i used app engine). The intern made the project evolve for more than a year.
A 10x developper is not just able to produce more, it can prevent you from falling into traps that can simply lead your product to a complete failure, and your company to simply cease to exist.
Furthermore, I do want to note that understanding user needs can greatly improve your effectiveness. Because not building something can save you multiple weeks or months of programming.
I take it you mean something like this: In the real world, NP hard problems are "solved" by approximations; and the range in the accuracy (and speed) of various possible approximation algorithms is immense in many or most cases. Which means you want your best woman doing the job, 'cause she's easily ten times better than the next man up, in fact her final algorithm might be thousands of times better and faster than her previous try last week and yet still leave a crazy amount of room for improvement, one day.
Infinitely times better? There are just some problems that bad programmers, no matter how much effort they expend, will never solve. Even if I take 10 years to solve a problem that a bad programmer will never solve, that makes me infinitely more productive on that sort of task over the bad programmer.
"But how many problems like that will you ever encounter in your career?" If you're content being nothing more than a CRUD website developer, then not very many. If you want to do more with your career than collect a paycheck, then you can structure a career around doing nothing but solving new, hard problems.
I'm a very productive programmer over most people because not only do I know how to do lots of things, I can employ them very quickly. I know it's popular to say we don't have to memorize things in the era of Google and StackOverflow, but there is a real, significant, large productivity improvement for not having to context-switch. I use Google and StackOverflow, sure, but let's be honest, most of the time is spent just trying to figure out what half the questions are even asking, say nothing about whether or not the "accepted" answer is correct and relevant to our tasks.
No, I don't have everything memorized. It's impossible to memorize everything. But that doesn't mean not memorizing things out of some sort of perverse spite is a winning strategy. No one strategy is the best strategy; a myth we consistently perpetuate in this field despite the constant evidence to the contrary. You have to employ all strategies. But all most programmers have is googling. I have googling and a larger corpus of memorized knowledge.
The value of a software development team is their ability to create new intellectual property similar to things they've made before. (Or maintain an existing system, of course.)
There is a small group of folks (charitably tiny, uncharitably maybe like 1/4 of all devs) who on average contribute negligible or even net negative overall value vs. cost to the code base as they work. And there are some folks whose individual work has a value of upwards of several billion dollars. In between there are perhaps bunches but it would be a stretch to imagine that there were only one bunch where the vast majority of other devs were collected within a single order of magnitude in terms of the value of their work.
And, make no mistake, I'm not just talking about moving up the "hierarchy" or the management chain in terms of value. Even if you restrict your dev. sample to just individual contributors with more or less identical work responsibilities (instead of say, junior intern vs. principal architect or somesuch) you will still find many orders of magnitude difference in value and quality of work.
The reason why this isn't objectively obvious is that so much of software is invisible. Yes, you can in principle read all the source code but in practice that's not tenable. And we still do not have all of the tools, models, or even terminology to concretely break down the structure of complex software systems into representations that aren't extraordinarily handwavy and overly simplistic basically almost immediately (compare, for example, an electronics wiring diagram versus a UML diagram or a layer representation). That coupled with the fact that software development is a creative and even artistic endeavor where the value of some piece of work can vary greatly between otherwise very similar examples (which is much less true of, say, bridges or diesel generators) means that estimating the value of a given developer's work a priori is enormously difficult. Indeed, that also explains why hiring is such a constant struggle.
Companies like MS and google have sufficient data to tell us whether the 10x programmer is a meaningful term.
A lot of being a successful CEO is being at the right place at the right time (of course: in addition to actual qualities).
Anecdote time:
I once was a franchisee of a major (services) franchise that some time ago decided to expand to Germany (I sold my franchise years ago). I'll only talk about one person, but this happened throughout the network, it wasn't nearly as successful as hoped in this country.
So anyway, I personally know one of the guys who lead one of the best franchises in a major German city. He expanded, became responsible for the entire wider area (which allowed him a cut from all franchises in it in exchange for recruiting new franchisees and for advising them).
He had this exact opinion (and he was a former business consultant too, I think he even has an MBA), when a franchisee didn't do well that he just wasn't good enough. He himself was proof, after all, just do your customer acquisitions and all the necessary stuff,and success will eventually come! It worked for him!
When a franchisee failed he acquired their shop, it was in the same city and they seemed to be in very good areas, lots of businesses that fit the description of the target market. Not a big risk one would think given that his own shop was doing exceedingly well with the exact same demographics, just a few miles away.
Long story short, he ended up giving up the franchise for the area as well as the two additional shops he had acquired. Today he has just that one original location. Turned out that the exact same extremely successful guy only managed to be successful in one spot. Not even in very promising areas just a few miles away did it work out!
There were more stories like this, some of them I knew personally (through franchisee training at the beginning where I met many of them), all people who were formerly employed and "important people" in their jobs, and who all thought that it's all about you and the effort and skills you put in. Some of them managed to indeed build a successful business, but they all became much more humble over time, because they all found the large amount of randomness in their success when they tried to expand (area franchise or another shop).
So, tell me again about those successful CEOs, I'd like to learn more... the books are full of such people, successful in one place and time and failing in another place and/or time. Because they themselves are only one ingredient into what is needed for success, and not even the major one ("necessary but not [even nearly] sufficient").
First, it's elitist. This isn't a professional athletics team, this is the workplace focused on engineering. Most places are not chock-full of the 10x'ers; I need to depend on other people to do things for me, and them on me; not all of us are 10x'ers, and it behooves all of us to work as a team. The 10x discussion distracts from that: a functioning team. Further, people seem to want to worship these "10x" programmers and forget about training anyone; we'll just hire 10x-ers only.
Second,
> Imagine traffic increases exponentially, and this average team setup an average website, with a data storage engine that’s hard to shard, hosting that doesn’t have enough redundancy, version control without proper backup, no CI environment, and no monitoring.
This is exactly the output I imagine coming from a "10x" programmer: that person has been able to output at such a constant clip by writing code with enormous technical debt. I've had to work on these systems, and they're a PITA: how productive could I be if I didn't have to deal with the decisions of the guy who, judging by the codebase, was shoveling code out the door as quickly as possible?
(i.e., what if a study held the programmer constant, and varied the environment? I bet I could be much more productive if I worked on a codebase that didn't fight me at every turn.)
Last, the assumption; the article claims there are numerous studies on the matter … and cites none. What we get is a SE answer that contains a dead link to an article containing citations, which thankfully was quoted in the SE answer (but screw hyperlinking to anything). The first I can't find, the second's abstract doesn't seem to support the notion of 10x's ("Understanding and Controlling Software Costs"; the abstract indicates that it's about understanding software cost estimation[1]), the third is a book, not a study, the forth is a study wherein the participants are told to use different methods of implementing the solution (the research appears paywalled, so I can only see the abstract; and thus, doesn't apply), the next is too vague to tell as it "summarizes the results of […] investigations in the areas of design practices, coding techniques, test/verification methods, and computer utilization" and is paywalled, the next seems relevant but is paywalled, paywalled, paywalled, this is also a book ("Peopleware"), this is also a book ("Software Productivity"), this one is relevant and available[2], but it doesn't look like a very big sample?, and the last two I've lost motivation to find.
[1]: https://ai2-s2-pdfs.s3.amazonaws.com/2147/c6218db2e35d40f4a7...
1. Those who are good developers 2. Those who can't write any real code (cargo cult or cut&paste developers, e.g. the 25% who I didn't hire over the years because they were not able to FizzBuzz)(25%-50% of the market)
The 10x comes from comparing (1) and (2) - although dividing anything by 0 is larger than 10x.
the 10x is just the guy that's already overcome this blocker that a more junior coder could spend a day on, and if the company doesn't encourage teamwork the junior is still taking a day and the senior is appearing 10x when he should be assisting other coders.
there's more value in a team being 3x than one person being 10x.