Personally, in the couple decades I have been in this business working in countless companies in Silicon Valley, I have met a few individuals that I think could be accurately characterized as 10x engineers. An important point is that they are not productive at just one type of development but genuine computer science and software engineering polymaths. They are incredibly rare but they do exist for all practical purposes. People that are 10x engineers never seem to think of themselves that way, it is how the other engineers think of them. It advertises itself; if you have to tell people you are a 10x engineer, "ninja", "rockstar", etc then you probably are not.
I will add that none of the 10x engineers I worked with were burning the candle at both ends. They did not work particularly hard compared to everyone else, they were just extraordinarily effective and consistent at making excellent choices in an engineering context and always worked very well with most engineering teams they needed to work with. I've never seen any of these guys burn out, they've been doing it for decades.
I would also suggest that it takes quite a few years of diversified experience before you can be a legit 10x engineer. Consistently making excellent choices requires both breadth and depth of knowledge and experience that you simply can't develop in less than a decade.
My starting point is this study by biz school professors (unfortunately paywalled) about how power law distributions define employees in sales, scientific research, entertainment, and really much of skilled labor: http://onlinelibrary.wiley.com/doi/10.1111/peps.12054/abstra...
In effect, it's common for 20% of employees to be responsible for 80% of a company's productivity.
I'm a writer at Priceonomics, so you can read the blog post I wrote about the research and the topic here: http://priceonomics.com/whats-so-special-about-star-engineer.... I'd love to hear what HN thinks in the context of this thread.
It's a longread. I think the most important points are:
1) You find star performers in many industries
2) Star performers are not inherently more productive - context is important. They are talented but also benefit from the system supporting them. In one study, the performance of 10x Wall Street analysts crumbled when they switched employers if their team did not come with them.
3) If you get obsessed with 10x employees and A players - and lose sight of important points like the importance of team - you will become Enron. Really. Enron lived and breathed the A players motto until their idolizing of "talent" lost all connection to reality. You can find a link to a great Malcolm Gladwell article on the topic in my post.
http://en.wikipedia.org/wiki/Alexey_Stakhanov
Stakhanov was held up as the >10x more productive coal miner; however, it's now generally understood that this was the result of a propaganda effort, and he had a team preparing and clearing for him.
This is a common risk in work-rate-measuring systems, how do you account for worker A spending time which saves the time of worker B? Especially in knowledge work, where the old guy/gal who does very little but carries all the oral history of the company in their head can be more important than anyone realises.
But there are a few things about star performers that I see. They tend to pick up the toughest problems and work on them. Importance to small yet important details. Extreme importance to quality, relevance and impact of the problem has on the real work and business scenarios.
In most ways, it has nothing to do with education, talent or skill. These are really good habits cultivated and sustained over time.
The key point from that being that it isn't so much that there are A players, and B players, it is that you only get true stars when the role fits the person. (Stated that way because it is easier to fit work to people than vice versa.)
Rereading the Medium piece now draws me to its relative lack of citation especially in the moral arguments toward the end, with a lot of judgments on a shaky empirical ground.
His commentary about "hitting the high notes" was new to me. It isn't just that 10x people are faster and make less mistakes, they also can do things that others can't.
This doesn't mean that you have to ignore culture, and tolerate bad behavior. But it does mean that in software it is worth the effort and cost to chase and properly manage the best talent.
What I've seen several times are engineers that are able to tackle problems that require so much creativity or skill that giving them to a less qualified engineer would most likely be a waste of everyone's time. In instances like that there can be a 10x difference in the value created by a quite good and an exceptional engineer. I've seen it in the static analysis software domain.
What would help is a reasonable study of them. Upon identifying these 10X'ers, does anyone analyze/interview them, their coworkers and managers? Dissect their team dynamics, like we analyze sports teams?
Can we empower people to become 10X'ers? Maybe it's not the 10X'ers themselves, but the happy co-incidence of person and institution? Do these 10X'ers merely thrive where others are miserable, like they enjoy boss-subordination or talk so much that others get bored, so they look great in relative terms? Does their job mandate Java, and they secretly use a high-level compiler which outputs readable Java? (I know someone who did this; seemed anal about indentation.) Do they initiate projects, and others basically maintain their quick 'n dirty designs?
This article isn't denying the possibility of isolating 10X engineers. Merely that the usual mental framework, which includes the "10X engineer" concept, has problems. Consider pre-Galilean frameworks which said everything comes to rest. Galileo's framework of frictionless surfaces seems absurd; when's the last time you touched a frictionless surface? In this sense, the old explanations seem more applicable to reality. Yet counter-intuitively, denying reality helped us discover more useful models. Do we necessarily want models which focus so much on 10X individuals, when that's not an ultimate goal?
I wonder if there's a bit of cause-and-effect swapping here. (i.e. perhaps many 10x engineers are that way because their sustainable work day allows them to have gained decades of experience)
This is just personal anecdotes, though, and not hard data. Also not a plan I'd encourage to follow. (One dropped out of a top 3 CS program to spend more time on professional projects. It was right for him, but again I wouldn't counsel others to do that.)
In college I competed in the ACM programming competition against Stanford. I was the only one on my team to write (working) programs; I personally wrote more working programs in four hours than either of the two teams (of four) from Stanford were able to write in six. Presumably these were some of the best programmers at Stanford that year?
I was a sophomore, almost completely self-taught, and going to a JC at the time. I learned a bit about data structures from a rather uninspired class there, though later I learned a lot about optimization in compiler design class at a four-year school.
While I was still at the JC I successfully completed a contract to port a game to a new platform for a major studio (you've heard of them). The original game was entirely written in assembly language, as was my port. It took about four months. While I was going to college.
My first job out of school I quickly ended up a star programmer. I wrote tools that were used by the whole company while working on a game. After a week of working on my first game there, I was told by the CEO that it already had better physics code than the previous developer was ever able to achieve on the last product they'd shipped (this was back before physics engines, so I was just writing code the way I'd figured it out on my own as a teenager -- later I learned what I was using is called an Euler Integrator [1]). The game I finally shipped for this company was also written entirely in assembly language, and it shipped with no known bugs. On time.
The next company I worked for, the same kind of thing happened: I ended up fixing tools they'd been using for months, optimizing one frequent operation that previously took minutes to complete so it would finish in less than a second.
Every company I've worked at (with one notable exception where I wasn't a good fit) I've very quickly ended up someone that everyone comes to for help (and I enjoy helping people). I had one position where I was supporting a lot of people on a forum in addition to doing a lot of new engineering, and the guy who ended up in my shoes later (who was himself an awesome developer) told me he had no idea how I managed to do everything that I did.
And I rarely work more than about 40 hours in a week, at least after my first few years on the job.
At this point I've done apps, highly scalable web server code, games (console, smartphone, and PC), video, graphics code, embedded device code, and programming tools. And I've contributed to multiple open source projects (at least one of them high-profile).
So am I a 10x programmer? Who can say. But I have only once worked at a larger company (the aforementioned "bad fit"), and am almost entirely self-taught. And I take pride in doing things other developers label as "impossible". But I have never had a "mentor" outside of the code and books (and more recently blogs) I've read.
I've certainly known developers who I could out-program by at least a factor of 10, and others who simply couldn't do some of the tasks I do regularly. But I wasn't TAUGHT this by other developers, though I am certainly standing on the shoulders of giants; I just arrived there by climbing, not being lifted.
Don't wait for a mentor. Go learn. Now.
However, an couple of anecdotes and some 140-character broadcasts hardly sway me that pronounced productivity differences are a myth.
I'd go so far as to say there are 100x engineers -- but it's not that they personally achieve 100x more than another programmer sitting in front of the computer. It's that they have the vision and talent to set a project up the right way from the start, so that the normal programmers can be productive. They're the difference between a project being delivered in 2 mos with a new batch of properly-working features coming 1 mo after, or a project taking 2 years with 8x more programmers, crashing half the time, and further features becoming impossible.
And then there are -2x engineers, who mess up things in the code base so bad that every hour of their work takes two hours for other programmers to fix or undo.
Then there are engineers that accomplish things that other engineers simply cannot. Call these infinity-x engineers.
No matter how much people want to call the 10x engineer a myth, there is a truly gigantic variation in productivity levels, which is especially magnified at architecture-level roles (where productivity can have a multiplier-effect on other engineers, for better or worse).
One example (out of an infinite set of them) would be if you need a software system that deals with massive amounts of signal processing on a power constrained real-time DSP chip. There are lots of people out there who are "Senior Software Engineers" at whatever company they work at currently (because they can create website solutions by stacking existing JavaScript frameworks with some glue code) who may never be capable of delivering that system to you. Not 10x later than someone who can, not 100x later than someone who can, not 1000x later than someone who can, but not within their lifetime and thus certainly not within a useful time-frame for your project.
And I don't mean to pick on web developers here, that's just used for example. There are plenty of people out there doing web development who could adapt to embedded system programming, or who already do both adeptly, but there are also plenty of "web programmers" who are really actually designers or glorified project management people with little to no aptitude for programming at all.
Also, I don't think this is unique to programmers. I wouldn't expect a general practitioner doctor to be able to perform neurosurgery and just have him take 10x longer to do it, he may just never have the "hands" for it.
A GP is certainly not a neurosurgeon, and therefore cannot possibly do the same job. Ditto with embedded programming vs a "front-end" developer.
But, if you consider only embedded programmers, would there be a 100x programmer out there?
As problems get more complex, the amount of time to complete them can go exponential for some developers. I've been forced to work with people like that; it really can be the case that some developers (who are otherwise competent) would simply never finish tasks that involve a crucial level of complexity.
And EVEN at just about any nontrivial level of complexity, where the time spent is only in the 1.5x-2x realm, the code written by the awesome programmer will likely be easier to understand, shorter, and easier to maintain.
Huge articles like the one linked are simply written by (and for!) the average competent programmer, to make them feel better. If you haven't worked with developers with a huge range of productivity, then you either haven't worked with a really good developer, or you've somehow lucked out and never worked with a poor developer. Statistically, it's likely the former.
I am definitely not a 10x anything, but my group once got handed a massive data-processing task that my supervisors--better coders than me, to be sure--believed was impossible to automate, and budgeted 200+ man-hours to do manually. I asked them to hold off for a minute and successfully automated the entire process in three days. That doesn't mean I'm an all-purpose supercoder; it means I happen to be really damn good at analyzing patterns in data sets. Give me work that I'm good at, but don't expect me to be that good at everything.
'10x' is about measuring productivity, and nothing else. A 10x programmer when it comes to HTML form validation might be really amazing at what he does, however may still be worth less than a 1x database administrator.
So which is it? If we're going to hold 10x up to the standards of rigorous research and conclude that it's bullshit, then by the same logic the rest of the article must be even more bullshit. (At least 10x has some experiments behind it.) By that standard, the only legitimate thing any of us can say on the subject is "we don't know".
But if on the other hand we're going to grant some validity to the folklore, then the most likely explanation for the persistence of 10x claims among respected software veterans is that it's grounded in reality, even though it's silly to take "10x" literally. (What the hell is "x"?)
However, as various people commented here, and I can attest as well, there are engineers who are orders of magnitude better than others. It's plainly obvious when you meet them and work with them for enough time to see.
So the interesting thing is why some people disbelieve their existence. If they haven't met such engineers, that is fine - they should be skeptical until they see evidence. But it is irrational for them to discount the eyewitness evidence of others.
So the really interesting issue here is why some people, like the article, want to deny the existence of such engineers. Are they threatened by them or something along those lines? I'm not sure.
(And of course "10x" is meaningless literally, etc. etc. But programming is a human activity, and we can measure our fellow humans despite how complex we are; for example we can say that some authors of fiction are hugely better than the average, such a thing is not even debatable.)
There are probably no 10x engineers, but I'm quite sure there are 10x teams. Better to focus on growing one of those than chasing a fairy tale.
Still, it really fed into the "only hire the absolute best" mythos that has spread in countless other harmful ways. Consider the aphorism "A players hire A players, B players hire C players".
The general message of all of it has always been: "You must hire the very best, even one merely good employee will poison the well and ruin everything".
Yet hiring practices are, as I said already, imprecise... which creates all sorts of bizarre behavior in the attempt to snag the "very best".
The research literature on programming productivity sucks, but not because 10x is a myth. It sucks because we have no reliable way of measuring these things.
I'm 10x more productive than my dad at physical labor, but a lot of that is because he's 75 and I'm less than half his age. Doesn't mean I'm any kind of physical labor "rockstar"...
There are many environments in which NNPP's are pretty much the standard, programmers that produce more problems and bugs than actual working and sustainable solutions.
In such an environment any competent developer will quickly stand out and will easily be labelled as a "x-times engineer", when all they actually are is just good at their job where others fail miserably.
The 10x myth is a way to give a positive spin on the shockingly common incompetence in our field.
I divide my officers into four groups. There are clever, diligent, stupid, and lazy officers. Usually two characteristics are combined. Some are clever and diligent -- their place is the General Staff. The next lot are stupid and lazy -- they make up 90 percent of every army and are suited to routine duties. Anyone who is both clever and lazy is qualified for the highest leadership duties, because he possesses the intellectual clarity and the composure necessary for difficult decisions. One must beware of anyone who is stupid and diligent -- he must not be entrusted with any responsibility because he will always cause only mischief.
It is the mix of talent, and dedication that puts some people above others (in terms of skills). Not some myth or anything.
I know about 1x engineers, maybe 1.5x engineers.
And I know about 0.1x and 0.5x engineers. They're the engineers who scraped by in college, whose heart isn't in it, who clock in and out each day and just try to stay under the radar. They're good at looking busy and getting nothing done. They make the 1.5x engineers look really good.
As one person who hired me said: there are an awful lot of people who want to have a fat programmer salary but very few who can tell me what design patterns are good for.
Basically once you get past the recruiters there's very little competent competition.
No one would bat an eye if you point out the huge skill differential between a professional musician or a professional footballer and an amateur. If it could be quantified, Yngwie would be at least 500x better electric guitar player than me and Messi 9.37e8 better at football. I don't think software development skill is all that different. In fact, it would be surprising if the difference between average and elite was only 10x when it is so much larger in other disciplines.
The 10x-100x engineers tend to have names like Carmack and Torvalds. So, yes, they tend to get what they're worth, in the end.
But using salary is a wrong metric, because a 100x programmer would be founding their own company, and the value they gain is sometimes worth way more than 100x the average salary had they remained a salaried employee.
There are a lot of 1x programmers out there. So many that it's very easy to be an "above average" programmer.
I am not a 10x programmer, but I'm not a 1x programmer either. I've met people who are 6-10x programmers, and they are incredibly good at what they do, to an extent that's hard to describe. I think it requires an even balance of skill, pragmatism, experience, and passion that allows someone to have that kind of performance.
And, do you average out the productivity, or is that the minimum or maximum? I mean, if you go on vacation, you are a 0x programmer for that time you are gone.
Basically, I think it's a silly thing that's been taken to far. Everyone is a 1x programmer compared to themselves, and a 10x programmer when compared to the right person in the right context.
The 10x concept contains not only the work but the decisions. Not just how to build something, but what to build.
For example, people other than Linus Torvalds can code at the level needed to write and maintain git--as evidenced by the fact that other people do that now; he has handed the project off.
But the creation of git included the conception of git--the many decisions about what he would build, and why it should be that way. Those decisions, coupled with solid coding, have resulted in a massive productivity multiplier for many thousands of people.
So think of somebody who would consider you a 3x. Now the engineer who is 3x relative to you is just about 10x to them.
Now consider the developers with net-zero or net-negative productivity. The 10x rule wildly understates how much more valuable a good engineer is relative to them.
Fabrice Bellard wrote (among many things) a linux emulator in javascript. (http://bellard.org/jslinux/)
I don't know how long it took him to write, but knowing he's also doing other things (http://bellard.org/) including FFMPEG, I don't think he spent his entire career on it.
The OP's opening "I was a 10x engineer for 7 months and then I was a 0x engineer for a year and a half." pretty much sums it up. I think many of us have at least felt to be in both places at different points in our lives. A "10Xer" can be loaded down with dreary (or extremely challenging) tasks that can send their "productivity" off a cliff. Either they burn out, or the nature of their work requires more "breakthroughs". If they are wise enough to refuse always saying yes to their bosses, they can become a wet blanket, which can also seemingly affect their perceived productivity.
(IIRC seeing a study several years back which suggested a 10x increase in cost to address an issue for each step later in the "requirements -> development -> acceptance test -> production" sequence it was identified; even if that's not true in exact numbers, the basic trend of escalating costs is and a developer that, on a team, leads to the team doing substantially better at identifying problems up front might get the code they directly write through the process from requirements complete to ready to test at the same speed as other developers and still be a 10x developer.)
And I digress. Every growing C programmer pass into a stage where he wants to push that Seasoned professional code into the least amount of lines possible. Even if nobody can read the lines.
With months of coding we can save ourselves a couple days of planning.
The design will not be ingenious. It will not take other parts of the system into account. It will not have simple tweaks done in preparation of future design change requests, tweaks that would make the code no more complicated, but many times more flexible. The code will not be as eloquent or as simple as it could be. A slight alteration to the initial design would have greatly simplified the code and ensured against bugs.
Then there is the opposite side of things.
The programmer who understands the greater business needs of the product, and writes code in anticipation of what is to come. Not entirely abstract to the point of ridiculousness, but with proper hooks put in that will be needed later. A software engineer who thinks past the most obvious implementation to what sorts of implications different designs offer. A software engineer who creates eloquent and understandable systems.
Yes one can argue that proper procedure and design reviews can enable the OK developer to reach the level of the Software Engineer, but at what cost to overhead? 2x? 3x? How many meetings, how many discussions?
There is a huge productivity difference between even experienced developers. Denying that is purposeful blindness.
Anyway, I kinda feel like just as there are 10x programmers, there are also -10x programmers. I'd say, even -100x. It's crazy how much time one person on the team can actually burn. One -10x person can suck up two 10x programmers' entire day with support and still create an absolute mess that has to be re-written. A piece of code that's solid will just run. A piece of junk can introduce bizarre, intermittent bugs that the team will be fixing for months.
I've noticed that -10x guys have a crazy knack for hiding their errors too. They'll figure out a way to get some botched code past unit tests and QA. Sometimes there appears to be an incredible amount of labor that went into circumventing every obstacle which was designed to prevent shooting themself in the foot!
Anyway, not sure the point of my post. But, I do believe that the 10x guys are out there and they can produce 10x without burning themselves out because they just have a way of looking at things that make them more simple.
This is evident even with something as simple as counting numbers - see this video http://www.youtube.com/watch?feature=player_detailpage&v=UMk... , and that's just the concept of counting.
However when it comes to whether they exist or not, here's an anecdote:
I was working for a TV channel and a piece of software needed to be 'actualized' (made over). By the time the other programmers told me the specs, over the office space, and started debating how long many days it should take, I was done (so roughly 1h).
Another point they make is that a group of people can generate compounded productivity. I live the exact opposite. Right now I'm sitting in an office with friendly people, and I roll my thumbs in boredom, but at night I work 1h for select clients and do more than in a week at my day job.
The only problem is loneliness. I hardly ever met anyone who enjoys multiple subjects (maths/physics/software/networks/biology/literature and capital management for me mostly), in fact I mostly receive jealousy disguised as mockery. Heck, I learned not to talk about seemingly arcane languages (Racket, LUA and the like) otherwise I'm cataloged and have to fight ridiculous prejudices. I found the best solution is to appear dumb.
Discrepancy between expectation of programmer productivity and the reality of one programmer can be very deceiving.
It correctly focuses on people that get stuff done. End of story. Some people drift and others paddle, simple as that. It is valuable to be able to tell the difference.
>It can provide a cover for destructive and abusive behavior by the “10x engineer”
Whole. Separate. Issue. Being productive has zero to do with being a jerk or not. People might tolerate jerks if they are productive, but that is a value calculation. People also tolerate poor public speaking or being chronically late or any number of other deficiencies for the same reason. If a person creates value they have more leeway, in general. So what?
>It erases many of the essential team and cultural dynamics involved in true productivity.
True productivity? As opposed to what? Productivity is productivity. This post assumes people are too stupid to calculate the long term effects of behavior and its relationship to productivity over time or to the output of the work group.
I think this post is trying to create an argument where none exists.
I find that particular research important for three reasons.
1. The 10 fold difference was consistently demonstrated many times.
2. Their research was conducted with professional programmers, in their workplace.
3. They were able to estimate the impact of a number of different factors, and they found that the single biggest impacts were workplace factors. (Ambient noise, dedicated office space, availability of white boards, etc.)
Admittedly they are unable to tease out why the connection exists between the workplace and productivity. Do productive programmers choose good workplaces? Or do good workplaces make programmers more productive? Probably a bit of both.
BUT if you're an employer, go read that book. Then consider your office plan. It is a lot easier to pay for a good workplace for an effective small team than to pay for a less effective larger team. Office space is probably not where you want to scrimp.
Edit: https://news.ycombinator.com/item?id=1995716. It sounds mean and accusatory to say on an internet message board that they made stuff up. But actually, our brief exchange was charming. He said it with a twinkle in his eye.
if a company does this, the employee should threaten to quit. Either they end up really quitting (good riddance - its probably a bad place!), or they realize your value, and pay you extra. No need for "promotion" (to another role/job).
I don't get why pay grade is tied to promotion.
When you find yourself greeted in the morning with things like "Hi, remember we had that chat about how to store timeseries data? I added an arbitrary-precision real type to the database last night and set it up", you are in the presence of one of those people.
(The other thing I've found about these people is that they are usually the opposite of rockstars. They tend to be quiet to the point of zen. Otherwise there are no worthwhile demographic indicators.)
1. Be one of the first in the project.
2. Make project messy (for example, by practicing narcissistic design [1]).
3. Don't do any kind of mentoring for newcomers, don't write any docs.
4. Be an asshole to kill newcomers' confidence.
5. When all other founding engineers leave, you will be 10x even by fair metrics.
[1] https://github.com/stuarthalloway/presentations/wiki/Narciss...
He is good at optimizing and using algorithms, but I don't think anyone says he is that good at writing programs. He popularized and sped up a lot of the techniques already in use. Raycasting wasn't anything new when John Carmack used it to build Wolf 3d (it was described as far back as 1982, 9 years before Wolf3d). It was also used in other games by other developers around nearly the same time, with games that were in development a lot longer.
As with any probability distribution of natural phenomena, there is a bell curve. There aren't a handle of 10x programmers and and bunch of 1x ones.
Even if the variance is much lower than people think, there would still be room for some number of 10x the productivity of some other person.
You were likely once 10x less productive than you are now when you first touched a new language.
Citing a number of reasons why someone may want to create this myth, does not make it a myth. Pretty ridiculous.
"10x engineer" sounds like a requirement a recruiter would put in a boring corporate job summary. Meh.
Enough said.
I am not that person. I am an average guy. I meet devs 3x my inferior, and 3x my superior. So I do think 10x range that MMM talks about is possible.
My second problem with the article is unit of measurement question. It is very clear what it is. A time to completion of a well defined task by an individual developer, with predetermined level of quality of the result. The problem is in the measurement. To measure you have to waste resources giving same task to many. And quality measurements are imprecise. MMM book was all about the time to completion. Obviously nobody counts lines of code. Why even bringing it up?
While I think 9x range is possible, I have never seen it in real life medium size teams. (I am a short term projects freelancer, so I see two companies a year over last 18 years) The reason being, my theory goes, a contextual one. Start-ups ship buggy code fast. A fab automation company might test a released code for a year before shipping. I believe it isn't the issue of A players hiring A players and B players hiring C players. It's just the goals differ. I was faster than most at a certain client of mine, but my code was less reliable. That was fine for a specific task I was hired for, but not for most what they do.
My third problem is that the article tries to fight the notion of importance of hiring 10xers. In many cases individual performance meters less. Imperfectly studied as it might be, 10x performance measurability beats other metrics of what makes a good developer, and a good employee. How do you measure ability to communicate, motivational power, leadership, and plain good taste? So for established companies 10x hiring is not as critical. And yet, I can clearly see why start-ups are focused on 10xers (ninjas etc). In start-ups individual devs have more autonomy, by design. Winner-takes-most aspect requires short time to market. Delivery times matter much more then quality. That being the case, hiring an obnoxious jerk who codes like hell makes clear if perhaps a temporary benefit.
So if you agree that for a startup time to market is a key, and individual developer relative importance is high, a logical conclusion is makes sense to search for (and overpay) the best. Just like it makes sense to fire 10xers once startup gets traction and replace with normally paid, normally performing guys that function great as a team.
