24 ms·
Busting the 10x software engineer myth
- WalterBright 5y agoI can cite many examples of a 10x engineer having an insight that greatly shortened the development time. It's not that they write code faster. It's that they select a path to the solution that is a lot shorter.
- avereveard 5y agoWriting code is the simplest thing in our job, once the problem and goal are clear the solution presents itself. Knowing what to write, what not, how to solve users problems and how to understand users problems in the first place so you know you're solving the right one up to users expectation, that is the hard part. A testing methodology that moves from programming kohans only tests the writing code part. Of course you find low variation there!
- mcv 5y agoPerhaps best is when they make other people more productive by pointing them in the right direction early on. Everybody has been stuck on a problem for days or more. Someone who can get you moving again by asking the right questions or pointing to an alternative approach can make you a lot more productive.
- renox 5y agoUnfortunately in big companies, pointing in the right direction isn't good enough: then you have to fight inertia, inter-team, inter-site disputes to finally do the right things :-(
- rualca 5y ago> It's not that they write code faster. It's that they select a path to the solution that is a lot shorter. I know a developer who likes portraying himself as a kind of 10x. He does not code faster, better, or smarter. His talent is managing his supervisor's expectations. He massages management to revise goals and shave off requirements, he is able to leverage even the smallest bump on the project management road to remove requirements and justify delays, and in the process he is able to put together a MVP that meets a fraction of the initial requirements and in spite of barely working does meet his manager's acceptance bar. In the end all that is left is the story where he single-handedly delivered a working product, he moves onward to greener pastures, and an unwitting team is left with the architectural problems, myriads of bugs, missing features, and the blame for stuff failing to work in production.
- random_kris 5y agoI think you are just salty. Communication is really important and seems like that dev was really capable at it
- rualca 5y ago> I think you are just salty. Communication is really important and seems like that dev was really capable at it I'm not sure you got the point. The whole point is that, exactly like OP stated, some of these self-described 10x developers do not code faster/better/stronger at all. They might even suck at it. However, they do excel at all the salesmanship required to descope critical features out of a project until all it's left is a fraction of the original project, and also excel at managing the expectations of all stakeholders so that the 1/10th of the project they deliver is passed off as the desired outcome. Once they succeed at turning a production project that requires a team to write into what amounts to a proof of concept that's doable by a one-man team, they find themselves in a position where a person alone can put it together. To put it differently, it's easy to run a whole marathon at 1/10th of the time when you succeed at moving the finishing line to 1/10th of the marathon's length. That requires skills, but they are soft skills and not hard skills, and you do not need to run faster than anyone else to do it.
- mpweiher 5y ago> they select a path to the solution that is a lot shorter. Yeah, I've also seen this. A lot. And selecting a shorter path often includes redefining the problem to be solved. In fact, as far as I can tell these kinds of differences are the norm, not the exception. From the article: > In a controlled environment, the variation between most software engineers is much more modest. This is almost certainly true, but completely misses the point. The point of 10x engineers is that they change the environment. They don't type in code 10x faster. If you don't allow them to change the environment, they won't be 10x more effective.
- patrickthebold 5y agoI'd add that its also in the design of things and deciding what to work on. I've seen small design decisions lead to a lot more (or less) work for the whole team. I've also seen teams work for months on things that didn't need to be done.
- jpgvm 5y agoThis is finally what allowed me to overcome my own self-doubt. I'm not the fastest programmer and I don't have the most intellectual horsepower either. What I do have is an enormous body of knowledge built up over many many years that allows me to select the shortest path or atleast guide people smarter than me into the right area of the solution space where it should exist.
- handrous 5y agoI'm mid-career, I guess, and these days I kinda feel like I've fucked up if I'm writing any serious amount of code, under most circumstances. The best solution is often a small script in the right place, leveraging existing software (when the best solution isn't "FFS, just pay a SaaS to take care of this, it's not even worth the time we've spent talking about it"). When I'm writing an actual project, I've got this nagging feeling like I just didn't know enough to avoid writing it. Like maybe I need to go RTFMs of the many battle-hardened daemons and OS components I have available and could be using. Any time I do achieve "10x" versus anyone else (and I think I sometimes do, though the broad "anyone else" makes that less impressive) it's usually because of what I didn't write.
- WalterBright 5y agoThe smaller a Pull Request I submit, the prouder I am of it.
- fouric 5y agoWhy not both? There's at least a factor of 3x difference between the volume of the most prolific programmers I know and the least. If John Carmack ships the product in 1/10th the time of Average Joe, I would call him a 10x engineer regardless of whether he picked a smarter design or if he simply implemented the dumb design 10x faster (or anything in between, obviously).
- dijit 5y agoI know "10x engineers" exist; some people are fakes and put forward things that look like they have high impact but are actually a bit shoddy. Some people like to be present and suck up. But some people really do just work hard, smart and have deep passion for what they're doing- and importantly: pride, which makes the quality of the content great too. Some of the best engineers I know "visit" bits of code or infrastructure and afterwards it's a pleasure to use and rarely if ever has weird bugs, and if they do have bugs they're easy to root out. What I'm trying to say is: high performers exist. But your organisation shouldn't be resting on the shoulders of those people. People leave. If your 10x (or 3x or 5x) engineer quits: are you really going to hire 3,5 or 10 people to replace them? Unlikely. And even if you do, institutional knowledge is lost. It's not a myth they exist, but you shouldn't depend on them.
- jmchuster 5y agoIf we're taking about is just output on a larger macro scale, then yes, hiring enough people will replace 10x engineers. But some things i think you won't be able to replace -- You won't be able to replace speed on short-term projects. Lots of people means lots of communication overhead, which really kills fast responsive speed. If you value time to answer, you'd prefer a small team of really smart people instead of a large team of average people. You won't be able to replace the insights. Tasks and knowledge are distributed amongst many individuals in bite-size chunks, so you miss out on insights you only get when someone holds everything in their head at once. You won't be able to have a small team / small company culture anymore. You have to be large, standardized, bureaucratic, catering to the least common denominator. And then make up for it with volume.
- j7ake 5y agoJust to give a concrete example: no amount of software engineers can be hired to produce comparable work of an expert cartoonist except by dumb luck. Throwing 1000 engineers won’t solve the problem. I imagine within the tech world there are tasks that are ill defined and a small subset of engineers can solve, but a typical engineer may not have the background to solve it.
- hawk_ 5y ago> Wrote hard-to-understand procedural code to 5000-line files. Did not actively share knowledge with his peers. The author seems to mean prima donna, not a 10x engineer and then goes on to destroy that strawman. Actively sharing knowledge, mentoring etc... and code and architectural simplicity are a given for someone who's 10x productive. Most of the costs are in maintenance not the initial delivery and a 10xer's output would deliver over the life of the software use. Hard to decipher code doesn't sound like it would fit that bill.
- anmxxx 5y agoIndeed! Did he get time to "share knowledge with his peers". Would he have been credited for it? Would his position in the corporation have gotten more secure? In a U.S. corporation, the answer to all these questions is "no".
- tempodox 5y agoI strongly suspect those conditions are not confined to the US.
- garybake 5y agoThis here. I think the author is confusing what a 10x developer is. I took the 10x dev to mean somebody who may work efficiently but also improves all of the devs around them. Improving yourself by 2x is one thing but improving the team around you by 2x is where you get the 10x.
- sneak 5y agoNo, the 10x developer is someone who, alone in a room, can ship in y period of time the same thing it would take 10 median developers y units of time to ship, or one median developer 10y units of time to ship. Because of the mythical man month, the 10 will actually take >y time to do it, due to coordination overhead. The 10xer will still ship the item in 1y. A big part of the leap from 5x to 10x is being able to dodge communication overhead. Some are also good at boosting their team. Some only work well alone.
- ernopp 5y agoHere we go again.
- tonyedgecombe 5y agoI don't know why but this idea really seems to rub some people up the wrong way. Yet we all know that on a big team only a handful of people will be doing the majority of the work.
- anmxxx 5y agoThis is a silly framing of the 10x engineer issue. That label originally designated someone who had written an unusual amount of excellent software. Recently in the discussions here, people take it to mean someone who cobbles together broken apps at a rapid pace and gets credit from management for being a hero. This is not what 10x engineer means. Please find another label for that phenomenon, for example 10x faker.
- eurasiantiger 5y agoI don’t think that’s a fair labeling; from my experience ”cobbled-together, broken apps” are the result of taking the MVP approach to continuous development due to time constraints imposed by management due to contracts sold too cheap by sales directors. The failure of a software project begins at the contract stage. This gives salespeople a measure of control over the developers, and it is in their interests to increase developer stress by selling more things cheaper. The worst part is that salespeople are prone to corruption: if they can make a client company pay less for a service, the company may hand over a part of their savings. This is difficult to control, as the kickbacks may come in material or immaterial forms. The effects of the corruption are very real to the organisation, which now puts undue stress on developers with projects that are designed to fail just enough to trigger contractual clauses in benefit of the buyer.
- jjav 5y ago> people take it to mean someone who cobbles together broken apps at a rapid pace and gets credit from management for being a hero I agree, but as you say, this is more often than not the definition used (unconsciously) by management. Management considers this person the 10x and others consider them the -1x. And yet.. these developers are also great though, in their niche. It's awesome to have someone on the team who can whip up the demoware in an evening for investors and customers! Even when I'd rather they never commit anything to the product source. Which is why this discussion of finding who is the 10x is misguided. Turns out people excel at different things. Good management will identify what everyone is best at and have them focused on that. Bad management will shoehorn people into the wrong roles and set them up for failure.
- codeflo 5y agoI think this is a nice strawman. The difference between an engineer that writes truly good code and pushes the team forward, and one that is simply the only one left that understands their own mess should be obvious to anyone, except maybe the most stereotypically clueless manager. "10x" is obviously a buzzword and not a literal measurement, but is there any real doubt that productivity differences exist? Or is is just fashionable to not admit this anymore?
- alexdowad 5y agoThere are some good points in this article. At the same time, "10x engineers" are not a myth. Anecdotally, I have seen plenty of situations where the most skilled engineers in a group were many times more productive than the least skilled. If anything, "10x" greatly understates how big the difference can be.
- onion2k 5y agoI think this is true for any group of engineers - some will be much more productive than others. That isn't because those engineers are better, or "10x" though, it's simply because they're working on a problem they find interesting in an environment where they're thriving. The less productive people aren't enjoying the problem they're solving, or there's something about the company or team that isn't right for them. Most capable engineers have the potential to be "10x engineers" compared to their peers if they find a problem they're passionate about in a company that works well for them. The real unicorn engineers are the ones who are able to drop in to any team and be like that.
- deleted 5y ago[deleted]
- gtujbkoj 5y agoHe's not even busting the myth. He says 10xers exist, but they are bad for the company.
- eurasiantiger 5y agoNo. He puts up a strawman argument, representing ”10x engineers” as producing shoddy work and not sharing information, which he then presents as being bad for the company. That is not a valid argument—obviously people like that are bad for a company, but those people are not ”10x engineers” even if they may sometimes be perceived as such.
- deltree7 5y agoSure, Jeff Dean, Vitalik Buterin, Dennis Ritchie destroyed their companies because they were 10x (or 100x programmers).
- EliRivers 5y agoI 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 ]
- snovv_crash 5y agoAs much as I admire Peopleware, I think on this it misses the fact that there are "negative"-X programmers. Adding them to a team means the team gets _less_ work done, either through endless questions, dodging responsibility, demotivating others etc. In this kind of best/worst metric you end up with above-infinite-X programmers, because the worst you could give a working system to and they will break it. Once you filter out the worst, I've still seen 10x-vs-median programmers. They have some insight which collapses a buggy, never-complete 50kloc library into a 50 line function plus a call to a SAT solver, or have some deep understanding of the underlying system that lets the whole team avoid spinning its wheels on an impossible-to-diagnose bug. These people are worth 10 ticket-closers any day of the week.
- bendbro 5y agotl;dr FILL YOUR EMPTY FUNGIBLE DEVELOPER SEATS WITH OUR FRESHLY TRAINED DEVELOPER CATTLE FROM SCHOOL OF PROGRAMMERS #36. CERTIFIED IN AGILE BEST PRACTICES AND ADVANCED JAVA BEANS. 2 YEAR SERVICE LIFE. PRODUCT OF DJIBOUTI.
- noptd 5y agoThe article seems to argue that you shouldn't focus specifically on hiring 10x engineers, not that they don't exist at all. Bad/clickbait title? Some people seem really uncomfortable with the idea that individual performance can vary massively from person to person.
- tibbar 5y agoSo… 10x engineers exist, but they don’t count because their productivity comes from superior knowledge or other factors? This is sort of silly. Just because you can ‘control for a factor’ doesn’t mean that said developer isn’t 10x more productive than everyone else. And providing one example of how this can go wrong says nothing about the general case.
- lifeisstillgood 5y agoWow - an actual intelligent well thought out post on this very crazy subject. I agree with them ! And love the call out to psychological safety, an important and usually under- values area
- Scarblac 5y agoI am currently becoming so sick of WFH and boring to-dos that I am making the 10x software engineer myth true for all of you. You can thank me later.
- xiphias2 5y agoSatoshi Nakamoto is a great example of a 1000x engineer (or a bunch of 1000x engineers) with an impact measured in trillions of USD, but the article may be right that he wouldn't have been able to have that impact inside a big financial organization, as his engineering is disruptive.
- tonyedgecombe 5y agoIf you measure his impact in turns of extra CO2 emitted you might take a different view.
- xiphias2 5y agoIsn't that true for any trillion dollar industry? Industries use energy whether you like it or not, and it's unfair to make such a big deal from one just because it's adopted in a different pattern than others. Agriculture, mining, electricity, transportation, defence...all have CO2 emissions, and it's extremely hard to get rid of it.
- tonyedgecombe 5y agoYes, except all those industries produce something useful.
- johanneskanybal 5y agoVery sf-type of term, is it still in use? From an eu perspective the idea to rely on some members of your team to be 10 times more productive than others seems like a terrible idea for anything longer than a 1 month sprint. That's not to say people's raw smartness, competence and experiences are the same just that a better focus would be growing the team as a whole.
- qsort 5y ago> From an eu perspective the idea to rely on some members of your team to be 10 times more productive than others seems like a terrible idea It's just less socially acceptable to say it out loud, doesn't make it any less true. If anything, 10 is a conservative estimation: the spectrum spans orders of magnitude. > a better focus would be growing the team as a whole Not mutually exclusive. Prima donna behavior is always inexcusable. If you can't work with others you're not 10x, you're 0x.
- cnlap 5y agoStrange that always the 10x is blamed for communication issues. The passive aggressive 1x, who try to undermine him, are a group and as such always right. I haven't seen a true 10x who was still writing code and growing the team. Time does not permit that, it is a fantasy. There are team growing "10x" engineers who shamelessly take the credit for everything.
- shantnutiwari 5y ago> Very sf-type of term, is it still in use? Yeah, I've never seen it outside the SF bubble. Where everyone seems to think they are the 10x, and everyone around them is a dolt.
- goto11 5y agoThe original study (if I remember correctly) showed a 10x productivity difference between the most and least productive students on a given task. I find that very plausible. In real world settings the difference might be much larger, since some developers effectively have zero or negative productivity. This article talks about a developer with consistently 10x productivity compared to the average developers in an organization. I think this is pretty rare. And I would consider it a warning signal. It means that either the average is really low or the hero is really a one-of-kind genius which will likely move on to a different job quickly (or get hit by a bus, per Murphys Law). It could also indicate (as per the article) that the 10x developer is actually keeping the other developers down, e.g. by insufficient knowledge sharing or writing unmaintainable code. You often see this if the 10x developers is "the old guy" who develops at night and hates meetings of any kind. Removing this guy will cause an immediate hit, but over time increase the productivity of the remaining developers.
- diarmuidc 5y agoDoesn't really bust the myth, though does it? Just says that the 10x engineer is a sign that the company may be in trouble, depending too heavily in such engineers. From 25 years in electronic engineering, I guarantee that there are some engineers that are 5x or 10x others.
- jordiburgos 5y agoA 9x mother will give birth a baby in 1 month.
- xfhgjxcfgh 5y agoA 9x mother will benchmark one baby per month. https://en.wikipedia.org/wiki/List_of_multiple_births#Nonuplets_(9) https://en.wikipedia.org/wiki/List_of_multiple_births#Nonupl...
- alzaeem 5y agoI work in ML engineering, and I’ve seen people work on a problem for the better part of a year with little to show for it. The non-progress gets on leadership’s radar, so even more resources get directed to crack what should be a solvable but non-trivial problem. An engineer who could have solved this problem without a fuss within a month or two is easily a 10x engineer. Not because they work 10x faster, but through better ideas and thought process, efficiency with their tools, and exercising leverage. This is even without considering their additional impact on the work of others. I think this could be applicable in any software or tech field, as long as the best solution to a problem isn’t trivial or immediately obvious.
- long_time_gone 5y ago==An engineer who could have solved this problem without a fuss within a month or two is easily a 10x engineer.== They also need the trust of their superiors to be listened to in the first place. A 10x engineer isn’t helpful if management doesn’t take their advice.
- olavgg 5y agoLike some football players, some software engineers are a LOT better than others. The measurement is value in $, which easily can be translated to 10x-1000x better.
- hyperman1 5y agoA fact I notice in a lot of teams and orgs, valid for both this and the 'heroes' discussion: Every organisational silo has,in the long term, exactly one 10x engineer, a.k.a hero. If there is no hero, the organisational silo will fail unless someone cares enough to take the role. If there is a hero, the need for a second one disappears. If a hero falls away, you'll have a few months of chaos after which a new hero appears. People will naturally give problems and hard projects to the best available person, and generally people agree who that us. So one person with a slight edge gets all the training and quickly gets much better. Heros are a consequence of organizational barriers. Update: That last part is inexact. Heros are a consequence of knowledge barriers.
- bjornsing 5y ago> Heros are a consequence of organizational barriers. Or organizational barriers are a consequence of heros?
- bjornsing 5y agoWhy do you think Ari-Pekka believes it’s the organization of engineers that creates long-term sustainable productivity? Hint: What does Ari-Pekka do for a living? Most people want to believe that what they do is the unique secret sauce of value creation, and they want others to believe it too. This is basically what you call politics.
- alenmilk 5y agoWell, my experience is that to increase productivity the most important thing is not doing things. If you can filter out the meaningless features and shut down products that are a product of politics (giving someone a product to keep them happy even though everyone thinks it useless) you can increase productivity much more than focusing on the technical aspects of development.
- ncmncm 5y agoI know an objectively measured 500x engineer. In the '90s, Siemens AG and Ericsson made a joint venture called Ellemtel for a classic six-month death-march project: if it completed on time, the customer paid. Otherwise, discarded. Each company sent 250 engineers. At the end of the six months, they delivered a working system. Fully half the code in it was by this one engineer.
- anovikov 5y agoIt's not like there are 10x engineers, it's so many 0.1x ones that a 1x one is nowadays seen as something of a miracle.
- ukoki 5y agoAnyone who has working in software for any length of time will have come across people who deliver orders of magnitude more high quality work than their peers: high output, high quality -- the 10xer. This post confuses that archetype with the similar-but-different high output, low quality archetype -- AKA the "cowboy", "hero", "prima donna".
- Brajeshwar 5y agoI have a different take on 10x Engineers. First, this is neither an exact science nor a multiplier (in this case, 10-times). I like to believe I have worked with a few of these "10x Engineers". I'm lucky to be technical enough not to be bullshitted by engineers and OK enough to sell to CTOs. Here is my understanding. They are not the ones who would produce XX times over a given period. It is not like normal/average engineers create X in 10 months; then they will do the same 10X in that same ten months or take 1-month to do it. The pattern I see is that the work of these engineers lasts a very long time and stays relevant for quite a long time. Everyone who works with them is happy because they learn a lot from the actions or are predictable. For instance, the QA team does not find apparent bugs or rare, most use cases, and the usual flow of actions and results happens. I believe the 10X comes at a much later stage, over time, when the work is a rock-solid framework and foundation that everyone else can pick it up and work upon it. I know I'm not very concrete, and I have to work harder to describe them in better ways. For now, it is more of a feeling I have after working with them. My only role was to understand them (not the technology) and shield them or cushion them from the BS-es that flow around anything that happens in a project/company. We used to nod and agree on these lines -- So, what are our BS-es that we need to tell the management/client to cross this hurdle. But remember, we still need to make that BS happen. Let me extrapolate the last part. So, I will huddle up the CxO of top Companies over a room, with concierge services waiting around to serve snacks, water, etc., but they won't be allowed to leave for a long time. Their phones are out of reach. When the other CxOs or executives are doing it, everyone else follows. I will throw around words like empathy; the design is subjective, iterative design, human framework, and all the jazz that pops up in my head. "The customer has to be able to find the shortest, simplest route to checkout." Then I will meet up with the team, explain what I promised, and we will, kinda, laugh and wink. However, we will now convert those "Design is Subjective" to Objective Deliverable Goals and Binary answers -- YES or NO -- does this work or not - when that checkout happens, what steps, fallbacks, errors, and everything. Companies eventually save a lot of money, as there aren't multiple iterations or griding other engineers 10-times.
- deleted 5y ago[deleted]
- einpoklum 5y agoThere may be 10x engineers. But what I know for sure is, that there are engineers (or engineering teams) which make you perform at 1/10x of what you might have, by mis-carefully laying a minefield of: * Build difficulties. * Hidden dependencies. * Multiple and conflicting sources of configuration information. * Lack of documentation * Incorrect/outdated/stone-cold lyin' documentation * Mis-named executables, configuration files, variables, constants etc. * Lots of global state * Inconsistent and surprising design choices. * Console noise inundation. So, the supposed "10x engineer" simply knows a few paths through this mine, while the rest of you just keep triggering them with almost anything you do.
- hsn915 5y agoMore broadly, the 10x engineer makes sure there are no such minefields. They make sure there are nearly zero hurdles to getting in the zone.
- einpoklum 5y agoAh, no, quite the contrary. The person who makes sure there are no such minefields makes a lot less great advances him/herself - they're busy working in a careful, orderly and considerate manner. And then the other engineers perform close to his/her level. That's not the 10x engineer. However, the person who lays the minefield may only be a 1x person talent-wise, but since he puts his colleagues on 0.1x, s/he is effectively the 10x engineer of that team.
- hsn915 5y agoIf people can perform so much despite the minefields, then these are not minefields. If we agree that they are minefields that impede programmer's performance, then by definition someone who does not make sure these mines are never introduced in the first place will outperform those who just leave them all over the place. > they're busy working in a careful, orderly and considerate manner. Actually no. It only takes very little initial effort. He spends most of his time producing actual work. Meanwhile, other people spend a considerable amount of their time fighting against bad tools and bad development environments. Worse, they might not spend a whole lot of "total" time fighting against the minefields, but their presence ensures they can never get in the zone (flow) and thus they always perform worse than their potential.
- user568439 5y agoI don't even consider myself a very good developer but I work hard, I have discipline and commitment, and I focus on getting the work done. This made me 10x engineer in most of the teams I worked. And for a few years I had it well measured because I was working with the same app and I was estimating all the tasks for me and the others with high precision to my own performance. The manager understood that other team members wouldn't follow my pace since they were less familiar with the app, and it was OK for him to estimate 2x or 3x the time when planning. But at the end it showed that I was average 8x faster (and with better quality) which was not justified since they were also senior even they knew the app a bit less. The worst part is that I was earning much less than them due to location... but at least I could justify a request for a 15% raise which was given with no hesitation.
- hsn915 5y agoThere are two things here: - What is a 10x programmer (what do they do better?) - What is the impact of their presence (or absence) on a company A 10x programmer is not someone who completes a narrowly defined task at 10x the speed of another engineer. > In a controlled environment, the variation between most software engineers is much more modest. Of course! If you ask people to implement a small component as part of a large architecture that was already decided .. you won't find much of a difference in performance (unless you have people who are truly and utterly incompetent). The excellent engineers would come up with a different design to begin with, but you can't measure that in a controlled study. Now, knowing that 10x engineers exist, how can you use that to your advantage if you're a manager of a company? If you yourself are not an excellent programmer, you can't just hire excellent programmers and hope they improve your business. You will be fighting with them over control. The key is to have excellent programmers in powerful position where they can call the shots about how to hire and manage and reward people. If you are willing to give them that kind of power, then you have no business reading articles like this on the internet. If you are not yourself an excellent engineer and are not willing to share power with excellent engineers, then no amount of reading of such articles on the internet will help you make the right decisions.
- karmakaze 5y agoAnyone who doubts 10x devs exist either never met a real one or is merely protecting their ego. Software development is complex enough that I'd go so far as to say there's even 100x range even among those considered competent. We accept this range in sports and art, what's the hangup? It seems like someone who just learned deductive reasoning and feels like they could now understand the universe then someone says there are 10x'ers and they instinctively go Noooooo! Sus are those who write to debunk it.
- yesimahuman 5y agoAgreed. They absolutely exist and I think 10x is too small of a multiplier for what they can do for a project and team. In particular, starting a significant project from zero often requires them. We’re fooling ourselves that they don’t exist and, if they do exist, are universally toxic.
- strken 5y agoI don't think anyone really doubts that some engineers will work an order of magnitude or more faster than others on a given task. They just think it's a misleading way to think about performance, which likely falls on a unimodal curve within your organisation, and likely differs by task. How do you know you're looking at a 10x developer instead of a 2x, a 9x, an 11x, a 500x, a 0.2x, or a 0.5x? The premise gives the impression that you can neatly split engineers into two groups, which is wrong. Your 500x engineers are only going to perform that way on tasks they've done before, your 0.2x engineer might just have the flu or might be an intern on his first day, your 2x engineer who wrote a parser for that weird proprietary format last week could be 0.5x this week because she's working on ansible scripts, and in general it's impossible to settle on a constant integer factor of engineering ability that does any better than IQ.
- prepend 5y ago> How do you know you're looking at a 10x developer instead of a 2x, a 9x, an 11x, a 500x, a 0.2x, or a 0.5x? This is the hard part, isn’t it. It’s hard to tell beforehand, but if you’re skilled enough you can look at someone’s contribution history and see what they’ve done over the past years. It’s not perfect, but it helps. Similar to how you review a 10x artist, just look at their work. I don’t think asking people if they are great is very useful.
- CipherThrowaway 5y agoIf you have a team of decent developers then I think the article has a point. But imagine you're in a situation where 90% of the developers on your team are outsource contractors with below junior level of aptitude who have been up-marketed by talent agencies as "senior architects" and "technical leads." Now 10x makes a bit more sense. Organizations with poor technical leadership fail to quality control hires and accumulate imposters. In this setting the lucky hire of a merely average developer creates the appearance of a 10x (or 100x) unicorn.
- eska 5y agoSoftware engineers that create negative value exist, so it shouldn’t be controversial that there are developers that go the other direction.
- thargor 5y agoThis is it. The truth is just that the average is incredibly low. That's why 10x or even 100x developers exist.
- graycat 5y agoI've never seen anyone be 10X better than, say, average consistently over a long period of time. But I've been 10X better than apparently average a few times a few weeks at a time. Uh, part of the reason for a few weeks at a time is that as part of the 10X I got the work done very quickly! My 10X cases were all when the planets happened to line up just right and, to use a baseball analogy, the work to be done was like a slow pitch right in my best strike zone. (1) I was seeing a girl, and she was an intern and working for someone who wanted her to work on some old Fortran code. She couldn't figure out why the code was giving totally garbage results. I glanced at her code and saw where she passed the constant 2 as an argument to a subroutine. So, sure, that can be dangerous. I glanced at the subroutine and, yup, it was changing the corresponding parameter so for the rest of the execution of the program the constant 2 had the value given it by the subroutine and was not 2. She worked a day or two on this, and I solved it in about 180 seconds. Why? I'd seen that in Fortran usage before. (2) I was in a software house working as a programmer and fast Fourier transform expert at a US Navy lab. Some engineers at the lab needed an extensive software project done and set up a competitive bidding situation. For one of the engineers, part of the work to be done was some power spectral estimation of ocean wave noise, that is, quite low frequency. Due to some earlier experience at GE, I knew the basics of the Wiener-Khinchin theorem and also got the Blackman-Tukey book on the statistics of power spectral estimation, typed in some code to generate synthetic ocean waves and accumulate and display the power spectra estimates, then called the engineer and we met and reviewed my work. The main point I had for him was that for the very low frequencies he was interested in, he could need dozens of hours of data and with much less data than that would be looking at small sample statistical fluctuations instead of good estimates of the actual power spectrum. Likely I got these results in 10X. Our software house got "sole source" on the work. (3) I was at Georgetown University consulting in applied math and teaching computer science courses when a friend from college called. He flew up to Georgetown with several other people, and we met. Everything was inconclusive -- no one had any definite, good ideas. The problem was scheduling the fleet for FedEx. That was important because some Members of the BoD questioned if the fleet could be scheduled at all; crucial funding was being held up; the company was at risk of going out of business. Finally in the meeting I just blurted out that I would solve the problem. Six weeks later I had the software running which was also the end of the semester for my teaching. I flew to Memphis, ran my program, pleased the BoD, pleased the founder F. Smith ("solved the most important problem facing FedEx"), and saved the company. I suspect that in time, that was a 10X effort. (4) I was working on a Navy project to support both my wife and myself through our Ph.D. degrees when the Navy wanted an evaluation of the survivability of the US SSBN (ballistic missile submarines) under a scenario of global nuclear war limited to sea. They wanted the results in two weeks. That timing just fit -- my wife had a vacation planned for us at Shenandoah just after the two weeks. From a WWII paper by Koopman's, I saw a continuous time, discrete state space Markov process subordinated to a Poisson progress and wrote and ran the software, Monte Carlo. The software was fast enough that I could generate and average 1000 sample paths quickly. During a peer-review, an objection was that there was no way I could "fathom the enormous state space". In response I mentioned that after, say, five days, the number of SSBNs left was a random variable; it was bounded and thus had an expectation; the expectation was finite; the random variable had a finite variance; the law of large numbers applied; and averaging 500 sample paths would give quite accurate estimates. I explained that intuitively Monte Carlo put the effort where the action was, and the reviewer, a well-known probabilist, responded "That's a good way to look at it." My work passed the review. A second person, actually two people, had been assigned as an independent effort. At the end of the two weeks, they made no progress at all. The Navy got their results on time, and my wife got her vacation on time. (5) When I arrived at Georgetown, a prof had just completed a statistics package. One of the routines was polynomial fitting, but on testing the numerical accuracy was poor. The prof had programmed normal equations, and on that problem the normal equations are close to the notoriously ill-conditioned Hilbert matrix. I wrote a replacement routine using some orthogonal polynomial methods and got accurate results. (6) I was in an AI (artificial intelligence), expert systems, project at IBM's Watson lab, and we were developing IBM's language YES/L1. We wanted rule subroutines. Our code design was to (A) return one call at a time from the whole stack of dynamic descendancy, (B) execute the RETE algorithm run-time code, (C) rebuild the stack of dynamic descendancy. I saw serious semantic problems with this approach and the coding was to take some weeks. I got some dinner, wrote and ran some illustrative code, in effect to call back into the stack of dynamic descendancy, at dawn wrote email to our team, got some sleep, returned at noon, and our programmer on the work was done later that day. I got an IBM award for the work. There were a few more 10X examples. I always put my pants on one leg at a time and have never walked on water in warm weather. None of these examples involved high stress. Instead the keys were context, e.g., I had everything I needed and background so that the work was in my strike zone. I don't achieve 10X all the time. Heck, I don't achieve 1X all the time; e.g., in my startup recently I've been interrupted and slowed by some unpredictable exogenous obstacles. But now it appears that I've circumvented the obstacles and am making good progress again. Back to it. Net: I don't think anyone can achieve 10X consistently over long time intervals. And I don't believe that very many people can just decide "next week I'll do 10X work." and be able actually to do it. Instead I suspect that most people can have 10X periods given the luck of the right circumstances.
- api 5y agoNot sure about the exact number before the X, but remarkably capable people exist in every field of human endeavor including engineering. I get the sense that some of this constant myth busting comes from HR people who want people to be interchangeable parts and don’t like it when they are not.
- flerchin 5y agoIf you haven't worked with one, you might believe it's a myth. Some folks, in the right place at the right time, are just better. Probably way more than 10x better, but dragged down by the same meetings overhead, at more than 10x the cost for no benefit, as everyone else. No I'm not one of them.
- 988747 5y agoThere's a twisted version of this "myth" that I encoutered: The demand for software developers grows much faster than the supply, so there is a temptation to hire wildly incompetent people, hoping that they still be able to deliver good enough product. As a result we have "1x" engineers, which are competent but rare, and "0.1x" code monkeys trying to get by. Or to put it in a different way: "In the land of blind, the one-eyed is a king".
- coldtea 5y agoYou cannot bust it because most of us have empirical evidence of a 10x engineer (whether it's 10x, 20x, or merely 3x doesn't matter -- there are engineers who can and hold projects all by themselves, with top-notch code and utmost speed and quality design).
- riztaak 5y agoAssign a work of an enginner to 10 engineers and it will become a work of 10 engineers. My experience is "10x engineers" are ones who work alone in independent manner, removing all dependencies that can potentially pin down their progress.
- go13 5y agoWell, if there are software companies that have 1.5x growth and there are that produce 10x and some produce 100x growth, then by definition developers in the 100x company are 10x more efficient than those in 10x company, assuming the factor a developer plays in company growth is significant. It feels like these myths busters are a bit left leaning. Sames as a topic about whether Tim Cook deserves his huge pay/bonus, to which the answer to the left leaning academic is, can you find a replacement for him?
- deleted 5y ago[deleted]
- bjourne 5y agoThis article is pure clickbait written to sell in this stupid Swarmia startup. :) 10x developers exist just like 10x musicians, 10x marathon runners, or 10x chess players exist. It may take a world-class musician a week to write a masterful symphony but it would take me way longer. Perhaps I'd never produce anything great so that musician would be infinitely better at it than me. Great chess players beat amateurs at least 99 times out of 100 so must also be 10x in comparison. Marathon runners run 42 km in like two hours but it would take me days to finish the same distance... It's true for almost any human activity that there is a huge gap between the worst, the average, and the best. It is preposterous to believe that the same wouldn't hold true for software development.
- z3t4 5y agoThe problem is that you can't measure a developer. So you can't say someone is 10x faster or better. If you add a bench-mark like how many LOC is written per day, most will exceed at that benchmark, but the overall quality will go down.
- cheschire 5y agoSchrodinger's project management: developers are measurable as long as they don't know they are being measured.
- eurasiantiger 5y agoBetter play it safe and commit more often.
- jgalentine007 5y agoI used to 'craft' commits but more frequent WIPs is what the people (who write the checks) want to see.
- Lichtso 5y agoYou might be joking but it actually has a name: https://en.wikipedia.org/wiki/Goodhart%27s_law https://en.wikipedia.org/wiki/Goodhart%27s_law Well, your idea is probably closer to the Marilyn Strathern definition.
- qaq 5y agoWell in the age of livestreams you don't have to guess you can just watch them work. To me pretty clearly Jon Gjengset Rust streams are what would I call 10X, although it all depends on what you consider 1x to be :)
- prepend 5y agoThe solution proposed is not good because it presents “hire 10x” and “support 1x” as some sort of exclusive options. Of course, the smart choice for orgs is to do both. If I had to choose a single (and I don’t) I’d go with a few 10x progs over dozens of 1x because small teams work better in general due to coordination overhead. This is no excuse for letting 10x be jerks and I would probably run away from any hiring notice that talked about 10x. I think this follows my observation that smart people don’t talk about being smart, they be smart.
- IAmNotAFix 5y ago10x software engineers are mostly 10x problem solvers who happen to be programmers. The driving attitude is refusing to work hard to accomplish something of low significance, which is mostly done thanks to: finding clever solutions, reducing feedback loops when debugging or testing, gaining proper understanding of systems to avoid empirical tweaking, asking around quickly when getting stuck, and also cleverly navigating company politics in order to ship something in environments where it is hard.
- hawk_ 5y ago> cleverly navigating company politics in order to ship something in environments conversely, company politics can be a reason why someone could be 10x in one setup and a complete dud in another.
- astrobe_ 5y ago> 10x software engineers are mostly 10x problem solvers who happen to be programmers I don't think it's just about problem solving, as in "solving a math problem". The 10x is, I believe, the combination of different factors: - Knowing you language and its ecosystem by heart: 2X - Knowing your codebase by heart: 2X - Mastering your tools (IDE/editor, Git,...), perhaps making your own tools: 2X - Using good development methodology (e.g. limit trial-and-error or do it thoughtfully): 2X - Being unsocial so people think twice before interrupting you: 1.5X So in my opinion, on the contrary being a 10X engineer has a lot to do with being a good programmer.
- ChrisMarshallNY 5y agoI see a variation on this article, several times a year. I can't speak for other cultures, but the US has a fundamental mindset that all but worships "exceptionalism." We like mavericks, rule-benders, and exceptionally talented individuals. Being attractive, and having a winning [public] persona is also very helpful. Sometimes, good actors can use attractiveness and persona to cover up for a lack of accomplishment and substance, and often, people of great substance, are ignored, because they are not attractive, have "problematic" personalities, or are not particularly good at self-promotion. I remember watching a documentary that compared the k-12 educational systems of the US, Germany and Japan. They looked at how high-performing students were treated, and how that affected their peers. The US would concentrate on high performers, often to the detriment of their peers. Japan would make high performers coach their peers. They seemed to decide that Germany had the best approach. I don't remember exactly how that went (I remember extremes). I'm a damn good engineer. Am I "10X"? I don't know, and don't care. I'm not in competition with anyone else. I get done what needs getting done, and I always have a ton of stuff I don't know, and still need to learn. Another thing about the US culture (I was not raised in the US), is that it is highly competitive. We can't just be good at something; we need to be better than someone else. That seems exhausting, to me. I'm not competitive at all. I have worked on high-functioning teams, my entire career, and was never interested in competing with my teammates. The team competed against other teams, but that wasn't really anything that concerned me.
- rory 5y ago> The US would concentrate on high performers, often to the detriment of their peers. That's very interesting. This is anecdotally very contrary to my experience in middle-class public school, and my sister's experience as a teacher in a lower-income school. Was the doc shot pre-NCLB? Is it simply a matter of variance across a large country, and my viewpoint is biased?
- ChrisMarshallNY 5y agoI don't remember. It was a long time ago. In my experience, this is exactly what happened, in my schools (I attended US public and private schools, after 5th grade). I saw it from both perspectives. I was very smart, and did well, when I applied myself. I could also be a nightmare slacker.
- throwaway4220 5y agoThey cite a study that concluded “while programmers are better and/or faster than others, the importance and scale has been greatly exaggerated.”
- ptero 5y agoThe article seems to make and fight a strawman argument, making a supposed 10x engineer a problem for information sharing, teamwork, etc. In my experience, it is quite the opposite: while very few of the 10x engineer are indeed "leave me alone to solve hard problems; figure out yourself how to maintain my solutions within the enterprise", the majority makes simple, robust designs that are easier, not harder for the team to understand and maintain. And when they leave, they generally leave behind a system that is stable and does not need day-to-day meddling from a senior engineer, which gives enough time to find a replacement. My 2c.
- deleted 5y ago[deleted]
- ridaj 5y agoIMO the 10x engineer is not someone who is 10x more productive than their peers. It's the person who will identify and solve critical engineering design questions far in advance, such that if you took them out of the team, the team would be 10x less valuable.
- ggambetta 5y ago"10x engineers" definitely do exist. Anyone who doesn't believe in 10x engineers just hasn't met one yet. I've had the pleasure of working with two 10x engineers. One of them is a problem-solving and execution machine. I could understand what he did, and I think that I could have done the same, only taking 10x longer. The other one... the other one isn't just a "faster me". His brain works on a qualitatively different way than mine. I probably couldn't have come up with the things he came up with, even with 10x or 100x more time. These guys are also incredibly humble and nice, and hilariously funny. Fantastic humans all around. Stu, Matt, I miss you guys!
- gurkendoktor 5y ago> Anyone who doesn't believe in 10x engineers just hasn't met one yet. Or they are working in a small and well-funded company that only employs ~10x engineers, and they have never met a (to them) 0.1x engineer.
- ggambetta 5y agoFair enough.
- ben7799 5y ago10x engineers surely exist IMO, but: - There are 10x as many pretenders for every one real one. Management might mistake the fakers for the real ones because they are faking it on being charismatic. These engineers wreak havoc on teams.. everyone else is cleaning up their mess, the fake 10x gets all the credit due to the charisma and ego and too often the rest of the team isn't able to reveal the true situation. Management will often give these guys (never seen a fake 10xer who was a woman) huge accommodations and let them go off on massive projects outside of normal accountability and project management and when they come back a year later they've produced a big mess of garbage but a year was spent and the guy is charismatic so management has to have it in the product. - Any given engineer might be 10x more productive in one organization than another. This can probably be indirectly correlated to the size of the organization - Fake 10xers can drag down everyone else's productivity, and make themselves look better in the process. - Real 10xer will produce an elegant architecture or solution that is easy to maintain and understand. The faker will produce a mountain of code with hidden bugs and put on an air as if no one else is smart enough to understand what they've produced. - There's an element of "emperor's new clothes" with revealing a faker. Everyone knows they are a faker except management, and yet it feels impossible to stop pretending and pull the curtain back. - Non-technical management makes it much easier for the faker to get their hooks into an org. Maybe the UI designer got elevated to VP of engineering and doesn't know much about code. Maybe a junior guy got promoted for being one of the first employees. These kinds of managers are juicy targets for fakers. - Fakers often seem to introduce new tech to the stack so they can show it off on their resume, even if it doesn't fit the product well. - Fakers make up clever names for everything they write as if they are marketing their code. Put stuff off in a separate library in a separate repo when it could have fit right in the main repo. Give it a clever name. Convince management to allow them to put it on github as open source so they can polish their external cred. My last two positions the team was essentially sabotaged by a fake 10xer on each project. Reams of buggy code and huge management accolades, when the bad code starts to catch up to them them move on and leave tons of tech debt behind, and they move on to do the same thing at their next position. One of these guys spent 3 years writing a crazy library that used an alternate persistence strategy and when it got put in it destroyed performance to such an extent that when he moved on the whole thing was removed in a month or two and performance went up 100x just by changing everything back to a more standard persistence strategy. Meanwhile alternate persistence strategy went all over the guys's resume/LinkedIn.
- chheplo 5y agoWhy do we even discuss this type of clickbait posts, few times every year?
- mgkimsal 5y agoIt's a completely context-dependent assessment. I was part of a team a few years back where I was certainly not a 10x dev. It was a team of... around 8-9 folks. 5-6 devs, PM, testers. There were jr/sr divides, but it was relatively smooth. My 20+ years of experience were helpful, but I wasn't 10x more productive than some of the lesser experienced folks on the team, and given the constraints and role I was in, there really wasn't a way to achieve that. I've been on other projects where the experience level and other factors really exacerbate differences, and I've absolutely been "10x" in comparison to the others on the project. The larger problems may come in with how you're treated, how you're viewed by management, etc. "In a controlled environment, the variation between most software engineers is much more modest." Well yes, but we don't usually work in controlled environments. With similar backgrounds/experiences, and strict project management controls in place, there's going to be far less variance possible.
- agd 5y agoOut of the 50 ish devs I've worked with closely, I've seen two I would say are in the '10x' camp. They were relentless in writing solid, simple, bug-free code, and doing so faster than everyone else. They were also effective in communicating their work. i.e. They weren't head-down in the corner savants. Their productivity was also significantly more consistent across a range of areas and task complexity, compared with other devs who would slow if working in an unfamiliar area or on a more complex task. Finally, good (and bad) decision making compounds with software. The right high level approach can pay easily pay of 10x over time just as a bad approach will result in buggy, bad performing software, and multiple rewrites. In short, this article does not match my experience.
- thargor 5y agoPeople often forget that 10X does not (only) mean quantity, but most of all quality. Also thinking in factors may not be the right approach here. We should look at it in a more binary way: Can a developer achieve the requirements or not? In most cases the magnitude of skill shows in what a developer can solve at all, not how fast he/she can solve it.
- alfiedotwtf 5y ago> In a controlled environment, the variation between most software engineers is much more modest. I have a feeling the writing has never worked with 10x developers. You know, everyone knows, that there's a galactic difference between the average team member vs that 10x in the corner crafting code like an artist chiseling into a block of marble. ... and then there's that awe inspiring, humbling privilege when you score getting onto a team where everyone are 10x-er. The variation between most software engineers isn't modest, it's a Mariana Trench of a difference.
- yobbo 5y agoThe point of the article is not whether 10x factors have been observed, the point is that (in all cases the author has seen) they are dependent on circumstances/environment and not the individual. Implicitly, he invites readers to re-evaluate their experiences. To me, this rings true for most mundane organizations (not id software).
- jyriand 5y ago10x developers exist, but often they leave mess for others to clean up.
- fassssst 5y agoI think 0.1x (or even negative x) software engineers are more common. The ones that introduce bad bugs, don’t accept feedback, don’t communicate well with PM and design, always want to refactor things… they can take a whole team down.
- deleted 5y ago[deleted]
- deleted 5y ago[deleted]
- lincpa 5y agoYou just need "The Grand Unified Programming Theory: The Pure Function Pipeline Data Flow with Principle-based Warehouse/Workshop Model" https://github.com/linpengcheng/PurefunctionPipelineDataflow https://github.com/linpengcheng/PurefunctionPipelineDataflow
- khaki54 5y agoIn my experience, it's possible to identify these people early career, set up their environment to help them excel, and help them 10x. Actually hire a 10x off the street? Pretty damn hard
- ltbarcly3 5y agoWhether or not some people in a given field are 10x more knowledgeable or productive than others is a question that can be answered. Whether trying to find 10x programmers is a good HR strategy is a separate question. This article is just a stream of consciousness brain dump, which I guess proves that 1/10x clickbait authors exist.
- zcw100 5y agoMy biggest problem with 10x is that I see it applied prescriptively not descriptively. If it's just describing some fact about someone's output then fine. If you've got the data to backup your 10x trophy then good for you but I don't want to hear some shit about someone being a 10x developer because someone else said they were. You also don't get to be a 10x developer by kneecapping everyone around you.
- khalilravanna 5y agoAs I get older, and maybe because I worked at a company whose product is “talent optimization”, I think a lot of the “10x” thing is just a function engagement and passion. That is to say it’s not entirely skill or “intelligence”. You could take the best programmer but if you point them at a project they don’t give a crap about they’ll phone it in. Point them at something they’re passionate about and they’ll have absurd impact. They’ll think of more novel solutions, test and refine those solutions, and crank out the whole thing in record time. If you want a 10x engineer, give them work they love.
- hnbad 5y agoI'd also qualify it by saying that a 10x engineer is not a 10x engineer for long if you burn them out or even if life just happens. I've met a lot of spunky young college grads/drop-outs who felt like 10x engineers but had no family, no hobbies outside programming and no social life outside meetups, conferences and work. I've also met people I'd confidently describe as 10x engineers who had all of that but in turn spent far fewer "productive" hours at work than the former. There's a common misconception that you need to find "young talent" and make them work maximum productive hours (who needs to do chores when you have a work-provided luxury cafeteria and laundry service?) to get the most value out of them like they're top athletes. Well, most top athletes retire before they hit 40. If that's your plan, you're not looking for 10x developers, you're just looking for more meat for the grinder.
- octorian 5y agoThis. Very much this. I've probably fallen into the "10x" camp myself at certain points in my career, and it was absolutely due to these factors. I should also add that having a general expertise of the problem domain and environment are enormous boosters as well. Of course the moment I'm considered "fungible" and moved to a project I'm not passionate about at all, I'm pretty sure this evaporates entirely.
- hu3 5y agoYep. I've seen 10x engineers become -1x when shoved into projects they hated. Their contribution became net negative to the project. And then return to 10x when transferred back to projects they enjoyed.
- netjiro 5y agoThe fact that this is constantly debated is sad. I've run numerous tests across various organisations. When measured it becomes evident that 10x is nothing strange. Set some real world useful target. Give the task to individuals or small teams and let them go at it, with regular followup. Measure time, defects, maintainability, whatnot. Perhaps add some real world change of requirements mid stream? I've seen solutions ranging from hours to never. What I see, and find very sad, is that most organisations have obstinately obtuse attitudes and handling of such simple analysis. It doesn't matter if the variance stems from intelligence, creativity, work pattern, experience, clever tricks, tools, processes, etc, etc. If it's faster/better then find out why, and learn from it. Can it be taught to others? Change work processes? Hire differently? ??? Whatever works. But ffs: measure, analyse, learn, embrace.
- notanzaiiswear 5y agoIs this just the IQ debate, or "nature vs nurture", on another playing field? It seems very obviously that some people operate on another level than others. If methods exist to boost the "normal" people to the genius level, they have not found their way into the mainstream yet. Surely you could bog them down so that they don't perform better than the rest. You could simply only have boring software issues to solve in your company. In that sense, maybe you could get rid of the 10 times developer. Or you could hire only very good people. But looking at the sea of developers, it seems clear that some are better than others.
- alberth 5y agoWho would you rather have, a single individual who's a "10x person". Or another individual who can make all of your developers 5x more productive, because that individual created a framework/algorithm/model that is radically more productive than what existed before (e.g. think Jeff Dean at Google, DHH with Ruby on Rails, etc)?
- travisgriggs 5y agoI’m not a huge fan of the 10X thing. I always feel like it panders to one’s vanity. I’m just a normal guy who enjoys what he gets to create. But I’ve worked with a lot of people over the years who I thought of as 0.1X. They often just don’t seem to care.
- trashtester 5y agoWhether or not "10x" exists depend on what "x" is. Some companies have very high hiring standards, so there the "1x" may be high enough that "10x" becomes really unlikely. But some companies hire almost anyone who can walk, and then "x"<=0, making 10x pretty achievable. I even expect that some consulting firms to this on purpose, at least if they sell services to customers that are put off by paying according to the value generated by the best developers, they bundle the best developers with teams of low-paid underachievers, where the lead is 10x as productive as those, and where the total output still matches customer expectations. Instead of paying $1000/h for one person they pay $1500/h for a team of 10 people, even if that one person could have more or less done everything on his own.
- dasil003 5y agoThis is a colossal strawman of an article, suggesting that a 10x engineer is someone who simply churns out features faster with a high degree of technical debt. It also talks about the "science of 10x engineers" being shoddy, and tends to regress to the mean under "controlled environments". This entire discussion is deep in pointy-haired boss territory. First of all, creation and derivation of value from software is not "a controlled environment". Attempting to define things such that you can measure them means that whatever individual strengths and abilities people have will be washed out along with whatever advantages they could confer to the organization. As much as management wants to commodify programmers and treat it as an assembly line, programming remains a craft. It's not construction to a blueprint, but rather architect, engineer and builder all rolled into one—and the output is data and UI interactions with abstract purposes and mental models, not physical buildings with very straightforward goals and constraints. The truth of the 10x engineer (or 100x or 1000x) is not that they code the same thing faster, it's that they find a better path. There are many different archetypes of this, you can't measure it, and you certainly can't hire for it, but with experience you can definitely see the impact of the smarter abstraction, the better anticipation of future requirements, the judicious application of YAGNI. As an engineering manager the size of what you can accomplish is limited primarily by how you structure the team and give everyone the opportunity to play to their strengths. It's not about adding process and bureaucracy to ensure everyone feels equal, it's about setting up shared goals and fostering a sense of camaradarie so that natural leadership can emerge and everyone can do their best work.
- htrp 5y agojust like every other domain, the problem is identifying the 10x dev
- jrm4 5y agoPssh. As something of an outsider, its far worse than "10x." There's just a fundamental mismatch here, which I think is the elephant in the room. Where there are people like Linus Torvalds and Kovid Goyal, you just don't need that many software makers in the way we do it now, unlike the way you need at least X amount of construction workers or dentists. Which, I believe, is not to say you can't have that many people working in IT, but a major shift of thinking is required. Software shouldn't be a product, and I'd go even further to say that it shouldn't even be a deeply centralized service. Rather, a lot of IT pros helping smaller individuals solve problems (and just happen to use software while doing it, in the way that e.g. astronomers happen to use math) would be best.
- codingdave 5y agoThere absolutely are different levels of talent between coders. But it is more nuanced than that - I rarely see anyone who is 10X better than everyone else at everything. But I do see someone who rocks one specific type of coding, while they are slow at others. Figuring out what skills you really need on your team, hiring the people who excel at those specific skills, and letting people spend most of their time in the area where they excel is how you get a high performing team. Also a pigeonholed team, though - there is balancing to be done in the long run.
- clipradiowallet 5y agoDenying that 10x <anything> exists is usually a shallow defense mechanism for our own egos. We aren't that good at <skill>, so we convince ourselves that no one else is either.
- jkingsbery 5y ago> One of the most interesting recent studies comes to a very different conclusion. In a controlled environment, the variation between most software engineers is much more modest. This is a silly comparison. The engineers I've worked with in my career that stand out don't stand out because they can write for-loops faster than others or public-class-Foo-public-static-void-main-string-args-System.out.println-hello faster than others. They are much more productive because they are better at ensuring they understand the problems they're trying to solve, and solving the problem with the least amount of superfluous work. > No one talked about the fact that this particular developer had been developing the same system for the past 15 years, the first five almost alone. He relished being “the best." Wrote hard-to-understand procedural code to 5000-line files. Did not actively share knowledge with his peers. Over the years, some capable developers had joined the company. Most of them decided to move on. The ones left were happy to coast along and leave all the heroics to the “10x engineer.” As a result, the company had great difficulties in trying to scale its development efforts. This example seems like a counter-example to me. It's important to separate out one's (potentially flawed) judgement vs the actual value an engineer brings. This engineer made everyone else less productive. Simply calling someone a "10x engineer" does not make it so. > The best strategy for most companies is not a relentless focus on trying to hire “the best” in hopes of finding 10x unicorn engineers. The rest of the article is a distraction from this generally good piece of advice. For many things, finding a competent programmer familiar with your tools and stack who can write the CRUD operations you need should be acceptable. A lot of software engineering interviewing distracts from this, with gotcha trivia questions about whether one can recite from memory algorithms from a text book that are not relevant to the work.
- didip 5y agoBah. Come on, OP. 10x engineers exist but much rarer than most think. Could you honestly see these people and NOT call them 10x engineer? * Fabrice Bellard * Linus Torvald * Chris Sawyer of Transport Tycoon * John Carmack * Ken Thompson * Jeff Dean
- poulsbohemian 5y agoI just wish employers would stop focusing on hiring 10x engineers, and instead focus on how to create an environment in which the overall standard can improve. What I mean is - you can take a superior engineer and put them in a crappy environment, and they will fail. Likewise, you can take an average engineer and surround them with support and they will produce a multiple of their raw talent. Focus on the things that make it possible to produce at a high level. For that matter, it strikes me that often those people that companies believe are producing at a high level, aren't. I saw this a lot in consulting - companies think Jimmy is just the bees knees, but in fact the reason he looks like a hero is that his junk is broken and he's constantly having to firefight to fix it. Often too, the loudest engineer in the room shouts down everyone else and "looks" like a leader when they are really the villain. I saw for myself - there were places in my career where I was super productive, and places where I hardly produced anything. It had everything to do with the environment: politics, communication style, teammates, technology, and problem domain.
- denton-scratch 5y agoAri-Pekka makes various plausible-sounding declarations, but he doesn't even try to make a case. I know that I've had many colleagues that were next to useless - even, possibly, exhibiting negative utility. Let's just give that kind a zero. Then there are novices - smart people with little experience. They can get stuff done, but they need watching. Suppose we give those a 1. And suppose we give an "average" dev, fairly smart, with a lot of experience, a 2. Such a person doesn't need watching, and gets stuff done. I'd say a zero needs to find more suitable work. A 1 is worth investing in. A 2 is most good professional devs. So what's this x10 fellow? Well, I rate myself as a 2. I'm a journeyman, and I'll never be a master. But the people I've met that I'd rate as "masters" were no more than twice as productive as I was. I can't imagine a dev that was 10x as productive as a journeyman. I've certainly never met one. Software development is a process of discovering and remedying bugs - from the requirements, through the design, to the implementation. These things take roughly the same amount of time, whether you are a journeyman or a "master". And once you have identified the problem, the solution is usually fairly obvious. If this notion of a 10x dev is a real thing, then I suspect it arises in people who regard technology as some kind of woo. If you're recruiting a magician, then he'd better be better than any other magician, because you don't know magic.
- jahewson 5y agoThe 10x is in comparison to the least productive engineer. In your model they get a zero so you actually have infinity x. Score your zero up slightly to 0.2 and a 10x is now a 2. It’s not so drastic a claim really. The common misinterpretation is that it’s 10x the average.
- denton-scratch 5y agoWell, yes, I was thinking the same way. But I'm aware that many of those I've rated zero are actually something negative, as in "Please stop writing code" (I was trying to be generous). I'm thinking of people with personality defects, who are also novice coders, who also think they're God's gift, and therefore won't take advice. So the score is a continuum, and there are negative (and zero) values. If that conflicts with the "x10" concept, then I'm not unhappy. I'm also conscious of the notion that some super-clever people can unexpectedly wreck an organisation or team, instead of sparking it off. It's not insane to think of a -x4 dev. Very smart, but anyone picking up his work has a mountain to climb.
- confidantlake 5y agoFor a lot of basic crud software something is very wrong if there is even a possibility of having a 10x engineer. I worked on a project that was basically just forms. Should have been really basic, anything a junior engineer could build. Nope! The 10x engineer instead built out his own form library. Incredibly difficult to use, obviously undocumented, extremely buggy. To build static forms with a little bit of validation. So yeah he was a 10x engineer because he made everyone else a .1x engineer.
- corpMaverick 5y agoA 10x Software Engineer is not somebody that can write programs 10 times faster. A 10x SE can solve problems that are 10x more complex. Because a 10x SE has a higher understanding and is able make design simplications and create better abstractions that allows her to not get lost on the complexity. Case in point. I have similar years of experience as Linus Torvalds and feel I am pretty good SE, but I couldn't have written git. Because his understanding is in a different level. I am able to understand how git works, but he was able to come up with the concept. I was happily using subversion but he knew what needed to be different and how to implement it. It is just another level.
- smlss_sftwr 5y ago10x engineers most certainly exist, I've had the fortune of being able to work with a few and their true impact isn't in the code they themselves write but in the higher-level strategic/architectural decisions they make that impact the team as a whole. That being said it is also my experience that most self-described 10x engineers are anything but, so if one bases their impression of 10x engineers off those self-promoting cases then I can see how it would appear to be a myth
- keskival 5y agoIt's weird to focus on time to solve a problem when the software field is full of examples of challenges where you need a great engineer to be able to create a working solution at all, and an average engineer could never in their lifetime produce a workable solution. What's the multiplier factor on these?
- adrianmonk 5y ago> The company's CEO would walk into the space where the developers worked and loudly comment – even to outsiders – “sometimes it feels like X is the only developer who gets anything done.” Their analysis: 10X developers are a myth. Alternative explanation: 0.1X managers are a reality.
- nborwankar 5y agoThe unit of software delivery agency is a team not an individual any more. That was in the days of Norton Disk Doctor where a single programmer held the whole problem in their head. The question that is lost in the noise about 10x is “Does a team with a 10x programmer deliver software better faster cheaper than a team without one. More formally is a team with a power law distribution of talent more productive than a team with a normal distribution of talent.” That is IMHO the question that really matters in terms of modern software delivery. Any thoughts on this question?
- BXLE_1-1-BitIs1 5y agoIn many cases, I had to step into an Augean stable of code, i.e. a 10x dev had to deep dive into code produced by 10 1x dev. Coming out the other end, functionality went up by 50% with 40% less code. Prior to being downsized at a multinational, I was asked to explain my database update scripts to a lady who had never seen SQL. Some of the queries took most of a page. That system slowly sank into the sunset. It's hard to do customer support when the database doesn't know about their new machines.
- mbrodersen 5y agoI have worked with 10x developers. And I have worked with -1x developers (stopping them from working made everybody else productive). Without the 10x developers things wouldn’t get done. Your demo/prototype wouldn’t be ready in time to secure the contract. Your production problems wouldn’t be solved fast. I suspect that certain (average) developers are jealous of the attention 10x developers (rightly) get. That’s understandable. But pretending that 10x developers doesn’t exist is silly. It’s like pretending that world class musicians/engineers/artists/… doesn’t exist.
- SergeAx 5y agoThose who believe in 10x software engineers are just dealing with 0.1x software engineers most of the time.
- Nuoji 5y agoAnyone trying to ”bust this myth” are to me suspect of either selling snake oil or just trying to defend their own mediocrity. If anything the problem is usually understated, as a big problem in larger teams become people who actually add negative net productivity to a team. Also, not to be forgotten (and also covered in books like Waltzing with bears) are people who act as multipliers to the whole team by making the team “gel”.