10x Engineer(medium.com)
medium.com
10x Engineer
https://medium.com/about-work/6aedba30ecfe
185 comments
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.
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.
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.
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.
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.
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.
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.)
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.)
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.
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.
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.
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.
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.
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.
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.
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 ?".
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 ?".
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.
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.
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".
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".
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...
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...
Agreed. This is a management problem. It is astonishing that here on HN someone could be castigated for spending more time thinking than typing.
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.
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 ;)
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.
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.
>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.
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.
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.
This is a highly irrational conclusion, even with the meaningless caveat.
>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.
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.
Generalizing through an extreme example is the problem. Risk analysis is about probability, and the probability of a face you recognize being that person is high; the probability of personality conflicts resulting in an office rampage are inconsequentially low. Should we extrapolate your support for illogical interpretations to a likelihood of psychotic behavior? After all, history tells us that they are correlated.
>Generalizing through an extreme example is the problem.
Why? It made my point that he was dangerous, though to an unlikely extreme conclusion, which I admitted was unlikely before I even said it. I would hope everyone reading comments here would be perceptive enough to recognize hyperbole when they read it, especially since I called it out as an exaggeration. Given that no one is likely to take it literally, what is the problem? What is the real danger you're warning against?
Not sure what your goal with these comments is, honestly. Seems like I hit a sore spot, given the temperature of your replies. Apologies if I somehow hit close to home.
Why? It made my point that he was dangerous, though to an unlikely extreme conclusion, which I admitted was unlikely before I even said it. I would hope everyone reading comments here would be perceptive enough to recognize hyperbole when they read it, especially since I called it out as an exaggeration. Given that no one is likely to take it literally, what is the problem? What is the real danger you're warning against?
Not sure what your goal with these comments is, honestly. Seems like I hit a sore spot, given the temperature of your replies. Apologies if I somehow hit close to home.
So, a hyperbole not to be taken literally. So why post it, boredom?
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?
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?
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.
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.
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.
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.
Could he be outsourcing his job? Has anybody seen him write the code?
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.
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!"
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?
He was the Product Manager for Excel during his tenure at Microsoft, so it's quite plausible he knows a few.
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)
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)
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 )
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.)
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.)
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'.
> 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
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
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
http://www.joelonsoftware.com/articles/HighNotes.html
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.
[deleted]
[deleted]
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.
However, an couple of anecdotes and some 140-character broadcasts hardly sway me that pronounced productivity differences are a myth.
[deleted]
[deleted]
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?
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?
The 10x is a huge simplification, but it doesn't make it any less true. Obviously there's a huge range.
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).
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).
Even the 100x is a simplification, of course.
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.
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.
but the criteria to which you ascribe to is one of education and training.
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?
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?
"A GP is certainly not a neurosurgeon, and therefore cannot possibly do the same job. Ditto with embedded programming vs a "front-end" developer."
Cannot possibly do the same job? Really?
I've done embedded programming, front-end web programming, back-end web programming, desktop app programming for Win32, Qt/Linux, game programming, OS system level programming and currently do mobile app programming, among other types of programming. And I'm not particularly special, I know quite a few other people personally who have done various combinations of these jobs and others at a high level of skill in each specialization. That's sort of my basic point is that really good and flexible programmers are not fungible products you can really ascribe any productively multiplier to.
Cannot possibly do the same job? Really?
I've done embedded programming, front-end web programming, back-end web programming, desktop app programming for Win32, Qt/Linux, game programming, OS system level programming and currently do mobile app programming, among other types of programming. And I'm not particularly special, I know quite a few other people personally who have done various combinations of these jobs and others at a high level of skill in each specialization. That's sort of my basic point is that really good and flexible programmers are not fungible products you can really ascribe any productively multiplier to.
i didn't say a person can't be both a front-end and an embedded developer. I merely said that a front-end developer (who is not trained in embedded programming) cannot do it. That you (or that there exists people) who are both doesn't have any relevance.
Bingo!
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.
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.
One of the many problems with the 10x Engineer concept is that it imagines that skill is a single dimension, when in fact it depends massively on context, environment, and the specifics of individual experience and the problem at hand.
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.
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.
In those three days, you were a 10x engineer - you accomplished 200 man-hours of work in ~24ish hours.
'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.
'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.
Also related is the myth that "an engineer" is a fungible resource. They are not. It's not one problem space. You can't swap engineers around like that, you have to match skill sets and experience to the problems you're having, or build new skills.
There is a trade off. If you don't swap your people around then they become very one dimensional. Sometimes it better to put someone less experienced in an area on a project so that he gains perspective (ie. see all junior staff)
A good point. A better phrasing would be "you can't move engineers around like that and expect them to be instantly productive". The problem is that engineers are viewed as being one dimensional as in "amount of engineering". Swapping for cross training, skill building, or just plain variety is quite healthy.
I just realized what was bugging me about this article. It points out that the empirical support for 10x claims is shoddy. That's fair enough. But then it switches to making a bunch of claims that have no empirical support: 10x is a myth, it's pernicious, it may lead to drug abuse, etc.
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"?)
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"?)
Well said. Without objective evidence, we should be open to the possibility of this being true or false.
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.)
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.)
Even if the 10x engineer were to exist, assuming a normal distribution, they would be extremely rare and highly sought after. To optimise your business around hiring such a precious unicorn would seem like a very foolhardy strategy. For one, simple probability suggests that you probably won't find one. And if you were to find one, could you be certain that it were a real unicorn rather than a horse with a plastic cone stuck to its forehead? And even then, what happens to the business you've built around it when your prized unicorn is stolen or passes away?
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.
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.
[deleted]
May not be normally distributed, but follow a power law (fatter tail)
10x was originally (man month book) the distance between extremes, not between the average and one extreme.
YES. What the 10X myth hurt most is probably hiring practices.
The thing that always got me is that even if they do exist, the candidate selection methods are, at best, a very unreliable way to identify them.
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".
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".
I spent Saturday digging out a basement with my son. The kid was a machine—for sure he did an order of magnitude more than I did. There's your 10x right there. If you can see it with picks, shovels, and a wheelbarrow, it's hardly implausible that you would see it in software.
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.
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.
Age, physique, motivation and balancing work with rest had nothing to do with it?
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"...
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"...
Of course those things have something to do with it! Who would ever say they didn't?
I thing part of the mythology about the 10x engineer stems from the very real and shockingly widespread existence of the NNPP or the "Net Negative Producing Programmer".
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.
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 like the way Mike Church put it in a Quora answer (http://qr.ae/NHgRJ): employees are either multipliers, adders (most common), subtracters, or dividers (fire immediately). Whether multipliers are 5x or 10x more productive is a matter of nebulous metrics, but there are obvious standouts whose presence brings a very nonlinear increase in value to the team.
The four-types classification reminds me of a semi-famous saying by a German general, Kurt von Hammerstein-Equord (http://en.wikipedia.org/wiki/Kurt_von_Hammerstein-Equord):
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.
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.
And yet if you look at high school students homework load, it seems bent on producing stupid AND diligent people...
hah, for the "stupid and diligent" programmer, i imagine someone who copy+paste a million lines of if statements, or write, ala http://thedailywtf.com/Articles/Laborious-Transitions.aspx
This hits close to home currently working as an enterprise web dev.
I remember when my boss told me I was a 'Rockstar' because I stayed up all night finishing a project by an unrealistic deadline he had agreed to for a customer. That was when I knew it was time to quit. Most of this is just ego boosting trumped up by managers or VCs or MBAs to get 'brogrammers' to try to compete to outdo each other with 'dedication' to the company. Sure some people are better then others but if you buy into an idea that you are a 'rockstar' or a 'ninja' or better then '10 other programmers combined', then I'm sorry to say but you're probably really just a 'tool'.
You make a strong point. This may be used to get people to work harder for the same (or even less) money. I have met talented programmers/engineers/developers. They had that a natural instinct towards computers. But they were not born as 10X. You can be highly talented, but still not be very good. The thing is, people who are born talented gravitate towards exploiting that talent. In computers, its the guys who are always thinking, talking, and dreaming about systems. The ones who sometimes stay up late because they just have to code. Or the ones who are obsessed over the layout of a PCB.
It is the mix of talent, and dedication that puts some people above others (in terms of skills). Not some myth or anything.
It is the mix of talent, and dedication that puts some people above others (in terms of skills). Not some myth or anything.
I don't know anything about 10x engineers.
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.
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.
Exactly. If you're going to talk about 10x engineers, the first question has to be ten times what.
I also know about -0.3x and -1.5x developers (we are talking about developers here, aren't we? Well, if not, replace with any other professional you want).
There are probably a few real "10x developers" out there but the reality is that there are so many lazy and under qualified developers out there that it's not hard for anyone who has put concentrated effort into learning to program to look like one.
Yep. I'm hardly a 10x engineer but time and time again people tell me I'm the only one to solve basic questions.
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.
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.
10x might not be a good description. It is not specified at all what is multiplied by ten. But I'm sure there are engineers that are capable of performing at levels far, far beyond the average.
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.
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.
I think the free market mostly answers this question. According to indeed.com, the average software engineer salary is $91K. So obviously a company (assuming they could properly identify them) would pay $910K/year to a 10x programmer. Are there people out there making that for pure coding (i.e. not management)? Maybe, but it seems doubtful. I would think that generally 99.9999% of programmers make less than $400K if they're just doing programming (I'm excluding things like options or equity in comp, which is mostly just a lotto ticket anyway). So the market seems to think that even the absolute best are 3x-4x programmers.
On the contrary, I've seen that options/equity is how the 10x programmers are compensated in most large companies.
Everyone has a 100-200k base pay and the average programmers get 50k in options, whereas the 10x one gets 500k.
Acqui-hires are basically, companies paying multiples of standard salary for exceptional programmers.
So obviously a company (assuming they could properly identify them) would pay $910K/year to a 10x programmer.
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.
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.
is Torvalds earning 900k/year? i dont know, but i have doubts that he is.
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.
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.
Following a Efficient Wage approach, productivity and wages don't grow linearly.
People who don't believe in 10x programmers don't understand that they themselves are probably 3x or 4x programmers, thus to them a 10x programmer is probably only a 2.5x or 3x programmer relatively speaking.
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.
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.
What about 10.1947x programmers. Or 5.345x programmers?
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.
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.
10.1947x programmers are a myth.
I think you don't know how to read.
I don't know how to respond to that. What meaningful insights am I ignoring that I should be picking up on?
The myth, present in the referenced articles and books, isn't that exists different levels of engineers, but that exists a gap between 1x and 10x.
Are you sure? I've never heard that aspect to it.
If I'm being generous, I'm a slightly above average engineer. Spot me 10X and I'll outperform any engineer on the planet. Do I believe in the 2X engineer? Definitely. 3X? Sure. 5X? Possibly, if their name is Ritchie or Torvalds or the like. But 10X? What I do in a week, they'd only get 4 hours. What I do in a year, they'd get 5 weeks. Doesn't exist.
The 10x "mythology" doesn't mean 10x productive as an above-average engineer. It means 10x productive as the least-productive.
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.
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.
[deleted]
Then the mythology is worthless. The focus should then be on eliminating bad engineers, not to go chasing after unicorns. Or even more importantly, figure out why some "10X" become "0X", or vice versa.
Yes. Remember this whole thing started over 40 years ago, when management still had the mindset of large teams of factory workers and/or office paper pushers. Some were clearly better than others but for the most part, employees were supposed to be pin-compatible fully interchangeable parts, so the idea that some people could be lagging so far behind the others without management's notice was a new and novel concept. Today, not so much.
Brendan Eich wrote javascript in about a week. Could you write javascript in 10 weeks?
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.
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.
I don't think the idea is that a 10x engineer doesn't do the same thing a 1x engineer does at 10 times the speed, I think the idea is that a 10x engineer delivers 10 times the value that a 1x engineer does (or the same value at 1/10 the cost.)
(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.)
(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.)
It's possible they can do things you can't do at all or can't do in a reasonable amount of time so 10x is certainly possible simply because they could have far superior knowledge.
I think the danger of the myth arrives from the idea that one can label some engineers as consistently 10X better than their peers, regardless of the actual tasks, personal lives, health, etc.
True, but honestly the 10x thing is only true because so many in the field are so bad that's it's not hard to do 10x more than they do. There are many copy/paste example and modify type programmers that can bang out work consistently yet do so very slowly and build very hard to maintain systems. Programmers who use virtually no abstraction and think it's fine to open a connection to the database and run some sql to get a result set and slap it on the screen and never once realize every method shouldn't duplicate the code to connect to the database and run some sql.
I think the issue is that you compare the 10x programmers to the average programmer. The original source say that you can see an order of magnitude of difference between a good and a poor programmer. Haven't you ever done in a week what a poor programmer took a month to (poorly) do?
There is speed of execution but also speed in recognizing that some work can be avoided. It's hard to measure how much work is spared by taking the right decisions.
I just finished reading the Mythical Man Month, and while it was certainly very good, the part of the book on 10X engineers struck me immediately as a gross oversimplification. Are there people that are 10X more productive than their worst peers? Absolutely. Are there people that are 10X more productive than the average peer? doubtful, or at least not consistently so, depending on their personal life and/or the nature of their workload.
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.
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.
OK, so there is an 5x engineer relative to you, and you're above average. And on the other side of the bell curve, there is an 0.2x engineer. This makes relative difference of 25x from the worst to the best - bang - QED.
How are you measuring performance?
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.
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.
I always thought of 10x engineer not as one that writes 1000 LoC while others write 100 LoC. Rather, as one that says, at an early stage of development "let's do it this way" and the total amount of manyears spent on the project (including maintenance etc.) happens to be 100 rather than 1000, which would be the case if second best approach is pursued.
There's an old programmers joke about this, which I'm not going to try and re-hash in entirety, but basically it's a listing of C++ code that starts off small, then as the programmer gets experience and learns how to do it 'better', the code grows, and grows, and becomes a massive engine of code. Then of course, as the years pass and the engineer gets more experience, the code shrinks and shrinks until it's slightly smaller than the original.
There's another programmers joke:
With months of coding we can save ourselves a couple days of planning.
With months of coding we can save ourselves a couple days of planning.
It's a hello world: http://www.ariel.com.au/jokes/The_Evolution_of_a_Programmer....
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.
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.
exactly. good engineers do less, not more.
tl;dr: denial of the 10X productivity we all observe in practice in any large group. Implies its not true until an 'official study' says its true, regardless of vast empirical evidence that supports this obvious fact.
That's a misleading summary. No one is saying that all engineers are equal.
Huh? The article repeatedly calls the 10x assertion 'mythology'. It disingenuously tries to 'debunk' the history of this assertion while blithely ignoring testimony from throughout the industry.
Besides, OP challanges the 10x programmer notion on the basis that there are methodological issues in the papers and books, and then goes on to list... a series of tweets.
Any article that takes a body of peer reviewed scientific research, points out some procedural problems, and then--without any supporting evidence--claims that their competing perspective is correct is bullshit. Scientific claims demand scientific refutals, not the agglomerated opinions of the twitter-sphere. This is exactly the same tactic used by climate deniers.
I have known developers who, given a moderately complex programming task, will complete it within a reasonable amount of time. The code will be correct with no more than the expected bugs, and the design will be OK as a stand alone piece of code.
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.
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.
YAGNI is a virtue. Make to code loosely coupled so the system can be modified in-place when the time come rather than building features that may not be needed in the future.
[deleted]
This is a valid thought, but I would piggyback on your comments and add that there are also engineers who put so much thought into their code - usually with the goal of eventual design expansion or reuse - that their code becomes over-engineered to the point that it, too, causes loss of overhead.
There could be two explanations - one is that the engineer who "foresaw" the future requirement just got lucky. The other possible explanation is that they really had a black art in deciding what's needed, and what's not. And black art takes time, and experience, as well as some level of intuition (some might say its heuristic - but heuristic is just shortcuts for lots of gathered experience).
Bingo.
I have done a good deal of studying of UX, I come from a background in testing, and I am now a developer.
Systems I design take all three disciplines into account. A junior UX team asks for something wonky in V1 of their spec, I code it to spec, and then make allowances for what V2 is likely to actually do. Typically a few extra fields in a struct, or designing a state machine to be a bit more flexible than strictly necessary. Maybe I break some logic out of the main class into a secondary independent one that can be passed around.
I have done a good deal of studying of UX, I come from a background in testing, and I am now a developer.
Systems I design take all three disciplines into account. A junior UX team asks for something wonky in V1 of their spec, I code it to spec, and then make allowances for what V2 is likely to actually do. Typically a few extra fields in a struct, or designing a state machine to be a bit more flexible than strictly necessary. Maybe I break some logic out of the main class into a secondary independent one that can be passed around.
This probably sounds arrogant, but I am pretty sure I'm a 10x programmer or at least 5x. I don't consider myself all that smart, though, I just seem to have a weird ability to get things done without much hassle. I feel like the 10x guys have a mentality where they're able to break things down without getting bogged down with the complexity of the whole thing. It's not that they're necessarily geniuses at understanding complexity - it's that they're able to break down complexity into simple parts.
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.
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.
You can argue with anything if you reduce it to a ridiculously absolutist statement.
But the bottom line is that there is a significant gap between the top 1% developer and average "let's see if I can google some code that does that" developer. Is it 10X? Who knows, no sane person can claim to being able to measure that exactly.
Have you ever taken compilers, operating systems, or some other project-heavy class? If so I'm pretty sure you've noticed several individuals completing a project with ease while the rest of the class, working in teams, struggles with. You can visit any decent CS program, any semester, and see this happen. It's no myth.
It might be a failure of the teacher - some concepts are difficult to grasp for some people due to the way their brains think. Some people think in different shapes, different methods. If the method your brain happens to like is the one that is being taught, then you might do reasonably well, by pure chance. If your brain's method didn't fit with the method being taught, you might not learn so well, and thus struggle.
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.
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.
I think it's hard to measure productivity differences, especially in terms of 'x' (times), but it's definitely not constant.
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.
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 over-focuses on the role of the individual and individual contribution in success, reinforcing Silicon Valley’s tendency towards hero worship, elitism and destructive individualism while ignoring the context of situation and privilege.
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.
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.
More studies will definitely help. I have a 10X engineer in my larger group and there's no question that he is one. Since I've seen this 'mythical' creature, I would not agree with the piece. Of course memetic transmission of the idea without critical evaluation can be harmful. However, color me paranoid but I see the sentiment behind this as being egalitarian and not meritocratic.
I find it sad that this article leaves out the (admittedly unpublished) research on the 10x phenomena, which is described in Peopleware. They consistently found 10x differences between experienced programmers on the same task, with the same tools.
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.
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.
Much as I like Peopleware, it isn't credible as research. The studies were never published, and the authors made stuff up, as one of them told me himself (I'll see if I can dig up the link where I wrote about it.)
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.
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.
How, exactly, is one supposed to cite unpublished research?
The authors of the book were the ones who did the research for their consultancy. But you could easily cite Peopleware itself for the research.
tbh, qualitative research like this has no predictive power. It's just a (few) case studies. The variables that are in these case studies cannot be controlled for, nor tested and/or predicted. All it gives is some example anecdotes. Unfortunately, a lot of social science research end up like this, because of the complexity of the problem. Thus, i wouldn't cite peopleware as research, but as anecdotal examples, or case studies.
Lets put it other way. Why someone should produce 10x more work, even if she/he could? Salary would be probably only 20% higher. And there is a huge pile of disadvantages (no holidays, extra support...). It is also career limiting move as someone becomes irreplaceable and can not get promoted.
> becomes irreplaceable and can not get promoted.
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.
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.
Let's face it: there's little to nothing that's new under the sun in software. Experience means understanding old but newly recast problems faster, and if you're lucky, solving their higher abstraction level equivalents the next time for greater apparent effect to the lay observer. As widely understood, the essential repetition of the solution act is something that bores good programmers. I frequently explain programming to others as not entirely dissimilar to floor sweeping. Who is the 10x engineer, then? Simple. They hit those areas that are simultaneously the most trafficked and noticeable, but perversely also the most ignored: the office fridge, the corporate atrium, the stained carpet outside the front door under someone else's management.
I'd say it's more of a binary distinction. There are people I've worked with who had no notion of their own limits AND had superior ability. Those people would do surprising things as a matter of course, that others might be able to do with time and planning, but most likely would never come up with on their own.
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.)
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.)
I've worked with a ton of programmers over my career and I know some that are truly better than the rest. But I only know one guy that is the 10x guy. He is filled with energy and cranks out good solid code every single day. This is after he bikes 20+ miles to work. And then 20+ home. He is a machine and I've never seen anyone like him since. That's one guy out of hundreds I've met. I tend to think everyone wants to be the 10x guy, but more likely they're just "good" programmers who want to be better. And that's not a terrible thing. Not every pilot needs to be Chuck Yeager, some just have to fly freight around in a way that doesn't get them or someone else killed.
I don't think the author is saying that there's no difference between productivity between engineers, it's exactly the opposite, there are so many differences and nuances that it's almost impossible to measure all of them. Your mood, chair, coworkers, boss, temperature, programming language, editor, task, etc. all have some influence over your productivity. You can't say "all things equal" because things are not equal in the real world. That's not to say that performance measure is hopeless but that it's as complicated as weather forecast: you have a huge ammount of variables.
Steps to become 10x engineer:
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...
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...
John Carmack was 10x.
I wouldn't go that far. Yea he made Wolfenstein 3d, but he started his work only after seeing a demo of Ultima Underworld (which was a much better 3d engine and complete game).
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.
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.
Jeff Dean
at building video game engines. Do you think he'd be 10X at building CRUD application after CRUD application?
He would probably figure out common patterns/requirements between them and build the best CRUD framework ever (possibly in Haskell), the only problem is that he would be the only person smart enough to use it.
Being 10X for a short duration is much easier than maintaining 10X over years. And also, are these people successful in terms of personal fitness and health? Is their home clean? Do they have good relationships with their family and friends? Do they spend time socializing, or do they spend all their time working? If being 10X is true, why haven't they figured out how to get rich yet?
If John Carmack is a 10x programmer, then trying to find 10x people for your organization is an absolute lost cause unless you're willing to shift your entire organization to be what he wants to do. Because there's only one Carmack and he does whatever the fuck he feels like.
It seems like Medium has become a magnet for articles that reference some science and then go on to draw conclusions that simply do not follow from that science, yet present the conclusions as if they do. The hollow icon article is another good example: https://medium.com/design-ux/a93647e5a44b.
Steve McConnell makes some good points regarding 10x SW engineers in "10x Productivity Myths: Where’s the 10x Difference in Compensation?" http://www.construx.com/10x_Software_Development/10x_Product...
I think the main problem with this concept is that everyone fits into two categories.
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.
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.
The thinking that gave rise to this article is a mess. It's not a hypothesis, but a FACT that someone can be 10x productive than 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.
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.
What are the units we are talking about here? Is productivity measured in hours and if so hours of what?
[deleted]
One way to measure productivity is how fast you can create what the marketing people want. I can't think of any way better than that, and it's really ambiguous.
I believe that was one of the points of the article. "10x Engineer" is being thrown around as another euphemism for "Rockstar" or "Ninja" without any true meaning.
For a given task, at a given time, there are for sure engineers that are 10x, or even 100x, compared to some other engineers. But that doesn't make them absolute "10x engineers", it's always relative to the task and the other engineers.
Do you believe chess Grand Masters exist? They're blind to invalid moves, they don't even see strategically penalizing moves.
"10x engineer" sounds like a requirement a recruiter would put in a boring corporate job summary. Meh.
"10x engineer" sounds like a requirement a recruiter would put in a boring corporate job summary. Meh.
It's strange that she criticizes the research basis for the 10x claim, and yet she's basing her claims about burnout and even alcoholism and drugs on a couple of tweets she received? What happened to source criticism?
You need a 10x environment to be a 10x engineer. Any 10x engineer can be held back by months or years of legacy and bad code cleanup to start getting to his 10x productivity level.
Of all the engineers you've worked with, if you can think of eleven such that you'd rather hire one rather than the other ten, then that person is a 10x engineer.
Does this even need scientific validation? There seem to be people who can't code at all, so if you can code, compared to them you are an infinity times engineer.
I work with a '10x engineer'. He works from 8 AM to 11 PM, like clockwork, every weekday. He is great to work with but I do not envy him.
"Talent hits a target no one else can hit; Genius hits a target no one else can see."
-- Arthur Schopenhauer
Enough said.
Enough said.
Off topic, I think its nice to see a pretty girl in the industry. Just saying.
The writer's appearance has nothing to do with this conversation. Also, given the amount of writing this particular writer has done on the topic of sexism in the industry, I'm going to assume this is some straight up attempt at trolling/derailing. Next time you feel the urge to "just say" something like this, maybe don't bother.
[deleted]
Too many words. Very few points.
Ah, but 0.1x engineers do exist.
My biggest problem with 10x is that it commonly misunderstood. The mythical man month (MMM) book explained, an average developer is 3x the worst. the best is 3x an average. So the dynamic range is 9x, but it isn't a math so who cares. And if you are an normal developer with a friend who 3x faster, it is a career guy in a company you would not touch with a long stick, that makes you average and your friend 10xer.
This misunderstanding makes people say 10xers are rare. They are not. People who are 10x better than you are rare.
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.
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.
What's the point of being a 10X engineer somewhere, if you don't own the IP? It sounds like a way to make someone else rich off your hard work.
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.