[jandrewrogers]

While the article correctly highlights the lack of rigorous scientific studies on 10x engineers, it also generalizes a bit too much from anecdote to make the argument that they are mythical creatures. A more reasonable argument is that the hypothetical existence of 10x engineers explains little about the productivity of most organizations.

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.

[alexmayyasi]

I would argue that the 10x engineer isn't a myth - the myth is that these 10x more productive employees are unique to engineering whereas they can really be found across industries.

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.

[pjc50]

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.

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.

[kamaal]

Its not about productivity. The net work achieved is totally by any means a wrong metric. What I mean to say is you can't measure human productivity in the same way you measure a machine's productivity.

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.

[btilly]

I think it is a very good article, which would have been greatly improved by mixing in, First, Break All The Rules.

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.)

[exue]

Paints a great+balanced high-level picture picture of the phenomena - I noticed it was submitted a few weeks ago without much attention. I'd also add reading about TopCoder and IOI / various competitions - star performers in another, highly measurable, field. Sometimes, absolute skill differences at the top may be small but in a competition environment lead to huge result disparities in wins/losses (see sports or eSports - every small advantage matters). Though mosts aspects of engineering aren't highly competitive, I'd argue similar features such as need for creativity or logically difficult problems, produce the power-law-like distribution.

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.

[eloff]

I've seen it in my workplace. We're very particular about who we hire, but even so the best hires have been more than 10x as productive as the worst over the course of a year. It's definitely a real thing.

[mathattack]

I feel obliged to toss in Joel's commentary... http://www.joelonsoftware.com/articles/HighNotes.html

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.

[gvr]

This resonated with me. If the programming tasks are somewhat mechanical/procedural, I am not sure that an exceptional engineer can create 10x as much value as a quite good one. I've never seen it.

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.

[waps]

I've worked at a lot of places and I clearly see it. It isn't very hard being a "10x" engineer if you look at the average programmer profile :

Arrive at 9:30, start out with 30 minutes at the coffee machine. They get mad if you discuss work at this point, or god forbid, talk about interesting algorithms or the like. They expect to be told exactly what to do, or they won't even sit down. If you don't give them an exact list of methods to implement in a class, nothing will happen. You can give them documents about the design, but they won't read them, let alone provide feedback. Not even after asking them 5 times. Similarly, when I started my recent project, I asked one of the customers for the canonical book on the subject and read (most) of it. I do not consider this special behaviour, but I'm definitely the only one to have done this. They treat this as normal, and if they make basic problem interpretation mistakes that would make you think a highschooler had mental problems, the reply is "it's in the design". Similarly classifying bugs correctly is impossible. A letter out of place in the UI they treat as equally serious as getting the wrong outcome in a financial calculation. If some programmer put "fucking" in some UI text (the one I talk about below), then we drop everything else, right ? They work to satisfy the exact wording of the policies, and never ask for (or tolerate in code reviews) exceptions. If you don't have 5 exceptions to the style guide and 5 things where they claim "sure, but the obvious unit test would be worthless, so I tested ...", chances are you don't understand the problem, don't understand the language well, or there is something wrong.

Of course, this is the "average" programmer at a place like a bank. I'm sure at Google or a few other places, it doesn't quite work like this. Being a 10x programmer is easy in a team filled with this kind of staffers.

I once had a guy that I'm totally unsure whether he was a fantastic programmer, or totally worthless. He'd be sitting behind his desk for the first week of the project. Almost without exception he wouldn't have his IDE open, but have an ipython notebook with some part of the problem open. Alarmingly often, he'd have hacker news, or dzone open and would be reading articles (I mean 50%+ of the time, not once or twice a day). Meanwhile his output in code was exactly zero for that week. Then, suddenly, in a little over a day (when he had claimed he could do it in an afternoon), he'd checked in the source for an entire module (that would have taken us probably a month to write, at least half a month). It wasn't 100% bug-free, but it was good enough to make the product functional. And while he took care of any bugs pointed out to him in minutes flat, for the rest of the week it was back to reading and experimenting (I think) mostly unrelated things. The problem is, this guy is not failure-free. He has these bursts of productivity, and sometimes he writes something beside the point (all programmers do), however it is really hard to ignore the week of wasted time when something he does gets rejected. We have a -sort of- working relationship, but it's not exactly smooth sailing. Any relatively independent and hard problem, he gets to do. And if something just needs to start working, we throw it his way. The result of that second part tends to infuriate other developers, but at the demo the UI works, with the project only half finished, which is something customers and managers appreciate. He tends to have his IDE open, modifying code, often while we're walking into the demo room, which doesn't inspire confidence to me. His reputation with the team is on a constant change. He's lazy, self-centered bordering on egoistic, can't follow instructions (granted, he generally makes good cases that the problem is with the instructions, not with him. But the frequency of him not following instructions is just so much higher than with the rest of the team it's not realistic). He ignores his coworkers, and of course they can't deal very well with the fact that there regularly are weeks with his productivity at zero. They don't feel to well about his productivity being off the scale for a few days either, by the way. Oh and once, he wrote 10 pages of code that implemented a complex algorithm, when we needed it, and all variable names were girl's names. Every single one. As in "for (int debby : kaithlin) {" type code. Why ? Because he had an argument with the architect.

So tell me, is this a good engineer ? Great ? Or a disaster ? He's not exactly a stabilizing force, that's for sure. There regularly are times when I wouldn't want to do without him, but most of the time, I'd like to make a hole in the window with his exact silhouette. More than one of his coworkers have mentioned something along the lines of "can't we fire him 4 weeks out of 5 ?".

[bjourne]

Man! It's like you were the manager at my previous job. I'll confess, most days I did spend my time reading hn, stackoverflow and working on more interesting projects than my assigned bug list. I usually came to work late and also took long lunches.

But you know what, at the weekly group meetings, my team leader could clearly see that my bug list always was empty while my team "mates" lists were overflowing. I told the department manager I had a lot of unused capacity. Not once, but several times. It didn't lead nowhere. When I fixed unreported bugs or did the "refactor the whole program while fixing my 3 assigned bugs" plan I was heavily criticised for that. All my suggestions for how the systems could be improved or what features could be implemented was shot down because they weren't in line with the department managers great plan for how things should be done. It just lead to long dick-size measuring arguments.

So exactly what should I have done? Sit with VS open, tap keys and simulate working all day long? Helping my colleagues with their problems was out of the question. As they, just like your department and this guy, talked behind my back and despised me because I only had to work 1/10th as hard as they did.

Eventually I quit because the situation became unhandleable. I got verbally warned for showing up late and people stopped even saying hello to me altogether. I was sick very often because it was better than reading hn all day which actually is fucking boring. My new job is like a breath of fresh air because the old one was really driving me crazy.

Truthfully, I can understand how it can suck to be average and have to work with someone much more skilled than you. I would also feel threatened if I knew about a colleague that could replicate what I do in a month in a few days. However, that's what HR departments, project managers and team leaders are there for. It's their job to make it work and if they can't and istead lose their truly great engineer, they suck.

[jtheory]

This sounds like not quite the same situation.

Much of the description (yours and the GP) is POV, though. I don't know you; maybe your suggestions for improvements were interesting engineering problems but horrible business decisions (and you didn't realize it); maybe your "several" requests for more tasks were actually 3 in 5 years, and were mostly actually scornful complaints about the low quality of your colleagues, though that's not quite how you remember them. POV.

There are more concrete checks, though -- can you list some of the things you did specifically to annoy/frustrate your colleagues or bosses, or even partly with that in mind?

E.g., did you ever implement a complicated algorithm with all variable names being girls' names? Did you ever intentionally fix this at the last possible second just because you enjoyed how uncomfortable it made the others? Etc..

Edit: My hope is that you won't come up with anything that silly, of course. I'm not actually trying to paint you in a bad light, just show how it's possible the situations could be quite different or quite similar.

Side note, though -- some situations really are untenable, some cultures simply don't reasonably allow improvement, but honestly most of the time I see one dev who's much more capable than their colleagues who is seriously resented that's because they are failing as a mentor... often because they simply don't think it's worthwhile ("I'm great, those people suck, and that can never change"). It takes some effort put into skillful social interaction, but most people want to improve their skills if given the chance in the right way. There will be some who just want to do exactly what they're doing -- and let you handle the hard problems -- and if you handle that relationship correctly they will appreciate you as well... but most resentment comes from people who want to keep advancing at a reasonable pace, and get some credit for doing good/interesting work, but instead they have the asshole super-dev who either says "oh, that's too hard for you, I'll do it" or "you think can do it, really?! well, go ahead, but don't come crying to me if you screw it up".

[daemon13]

In my humble opinion the guy is a great engineer who is bored (by lack of challenging projects) and discouraged (by less than stellar teammates).

It is rather easy to check though - you should forget about time spent on work and need to compare the outcome, i.e. result, of this guy vs every other engineer on the team.

If the check above shows that this guy is better than everybody else, than this:

>> Alarmingly often, he'd have hacker news, or dzone open and would be reading articles (I mean 50%+ of the time, not once or twice a day).

and this:

>> More than one of his coworkers have mentioned something along the lines of "can't we fire him 4 weeks out of 5 ?".

indicates one simple thing - he is not managed properly by his manager and by the company.

It as simple as that...

[gaius]

Agreed. This is a management problem. It is astonishing that here on HN someone could be castigated for spending more time thinking than typing.

[rwallace]

He's a good programmer whom you and your colleagues don't like, and by the sound of it he doesn't like you either. The solution I'd recommend is to have him working from home. Put him on a contract basis or whatever if that's what you have to do to clear it with the bureaucracy, but you should arrange things so you get the results he delivers without having to see his face.

[ianstallings]

I'd just fire him because then he could move on to something he enjoys more. It's not the end of the world, being fired. Trust me, I know ;)

[mathattack]

I'd say he's neither great, nor a disaster. Without getting inside his head, it's hard to say if he's very lazy and unmotivated, or if he's so smart because he's experimenting all the time.

Another observation: Being 10x is total contribution, not individual contribution. If you're fast, but others can't read your code, subtract that from the productivity. If you cause other decent performers to quit, subtract that from productivity. If you piss off clients, subtract that from productivity.

That's not to say one can't find a way to make eclectic people useful, but the smart jackass rarely ever lifts an entire team's productivity.

[SomeCallMeTim]

>So tell me, is this a good engineer ? Great ? Or a disaster ? He's not exactly a stabilizing force, that's for sure.

Sounds like he doesn't want to be working there. Sorry, but it's probably the right decision to encourage him to find a job that he wants. Elsewhere.

In a few of the behaviors he described, I find some sympathy. I do have a high opinion of myself, and at one job would end up in loud arguments with the CTO over how to do things. Sounds like this guy takes it farther, though, doing things that are spiteful when he doesn't get his way. That's a scary, pathological behavior, and that alone would make me think you'd be better off without him. I wasn't happy when I didn't get my way, but I'd suck it up and deal; that's the only professional response.

And speaking of pathological: It sounds like he's intentionally misinterpreting instructions when he can? Again, that speaks of passive-aggressive behavior. And he avoids other employees? Not to say that anyone is in danger, but you've painted a scenario that strikes me as the backstory for "the guy who cracked, came in to the office, and went on a shooting rampage."

Or he's just Aspergers. Can't really tell the difference from here.

[rhizome]

Not to say that anyone is in danger, but you've painted a scenario that strikes me as the backstory for "the guy who cracked, came in to the office, and went on a shooting rampage."

This is a highly irrational conclusion, even with the meaningless caveat.

[SomeCallMeTim]

>This is a highly irrational conclusion

I would admit to it being illogical, in that I didn't use logic to arrive at that statement. But it's an entirely rational statement: I arrived there via pattern matching, though, and not logic. Is it irrational when I look at a face and recognize it? If not, then why so with other patterns I recognize?

And it's not a conclusion at all; it's just an observation. People who are as obviously disgruntled as the employee in question often end up striking out. Some, a very few, strike out violently.

The employee in question has already shown evidence of "striking out," he just hasn't escalated past passive-aggressive behavior. I used an extreme example of striking out to throw it into perspective: He's not happy, and he's willing to do things out of spite, and that's a liability, even if he never ends up violent.

There are lots of scenarios that don't involve physical harm: Leaking confidential information. Cleverly hidden time-bombs in code that no one else understands. Lawsuits. Spreading discontent among employees.

[wisty]

It sounds like he's reasonable (skill wise ... totally unprofessional though). He also probably has a shit team, and shit management. Shit conditions make people behave less professionally (though he sounds worse than most).

Does he have any chance of being promoted, for not being a complete moron? Or do you promote morons into lead roles, so they can hire even bigger morons, and make moronic decisions?

If he's not going to get promoted, then he's got no reason to not just dick around, and behave like an asshole. Yes, he's probably hurting his chances of promotion (and might risk getting fired), but he probably had no hope anyway (since there's no way you could afford to lose him by kicking him upstairs). And what are you going to do? Fire the only guy who can actually solve problems?

[DennisP]

When I'm on a new project, I also goof off for a few days at first, sometimes up to a week. Then I crunch out a lot of code fast.

I don't really mean to do it that way, and I usually feel guilty during that first week. But apparently my subconscious brain is sorting things out. I try to work and it all just seems too hard and confusing. I make little attempts to start and they just seem wrong. And then one day everything suddenly clears up and it's all obvious.

[gridspy]

It sounds like you have a very smart programmer who is a little antisocial and very bored.

His value to you depends on how you structure his environment to make doing a good job more fun to him than torturing his co-workers.

There's a degree to which putting exceptional people with people who just do the job can cause both to resent the other.

[bulatb]

Could he be outsourcing his job? Has anybody seen him write the code?

[gvr]

This description made me laugh. Yes, clearly there's >>10x difference between a useless programmer and an amazing one - I've always thought of a "10x programmer" as one that is 10x more valuable than one that is merely good.

[mathattack]

For many systems, maintenance requires more effort than construction. Bad coders require much more maintenance. Some of it is from code not built for reuse, and some of it is for "Drop everything everyone is doing until someone can figure out why this isn't working any more!"

[gaius]

Question: how many 10x engineers want to work on a bug tracking tool? Is it likely Joel has met many of these guys, or is he just telling the audience what it wants to hear for some more page views?

[varjag]

He was the Product Manager for Excel during his tenure at Microsoft, so it's quite plausible he knows a few.

[calibraxis]

Such anecdotes are very difficult to evaluate. Suppose I told you I met 10X engineers. But that doesn't mean these individuals are really 10X engineers, merely that I believe they are. (Do you believe everything I believe? If you learned my politics, you may very well believe I'm a lunatic. So why believe any other observations I make of people?)

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?

[colanderman]

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 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)

[ltcoleman]

Your words are extremely accurate to me. There ARE 10x engineers but it takes a lot of experience to even have a chance at becoming one. A new grad ( even out of somewhere lik e Stanford ) has no chance to be a 10x engineer especially in a startup landscape (assuming a small startup with few extremely experienced engineers) without proper mentorship. The only people that i would say are 10x have worked at larger companies and have had multiple great mentors across many technologies ( once again the breadth and depth thing )

[mathattack]

I'm not sure I agree. I don't have too many data points, but I've observed a couple self taught 10x folks. Maybe they were paired with others racing up a steep learning curve, but they were at the leading edge of technology at a young age, and without seasoned mentors.

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.)

[silverbax88]

I have to agree with this. I've worked in small startups, large corporations, and for my own company. The reality is that only in the forge of big companies can you get the experience that makes you a badass engineer. Of course, just working in a big company is not an automatic ticket. But you take a good engineer with talent and put them in the right environment - for some years - and they will become what people might refer to as '10x'.

[msandford]

Yeah, I would agree. Also Spolsky has some pretty interesting data regarding the 10x programmer. It's students, not professionals but it does indicate that (surprise, surprise) things are distributed and it's smeared out quite a bit.

http://www.joelonsoftware.com/articles/HighNotes.html

[SomeCallMeTim]

> There ARE 10x engineers but it takes a lot of experience to even have a chance at becoming one.

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.

[1] https://en.wikipedia.org/wiki/Euler_method

[sbilstein]

Uh, I've known several engineers (ages 22-30) with very questionable drug/alcohol habits who work incredibly hard (65-90hr weeks being the norm). I don't know if it's addiction per se as much as the desire to 'go hard' at all times.

[samrift]

Indeed, the writing on this piece is good. And the fact is that the studies bolstering a "10x engineer" belief did have some flaws.

However, an couple of anecdotes and some 140-character broadcasts hardly sway me that pronounced productivity differences are a myth.