4 ms·

I read somewhere a report that suggested that top software engineers tend to be up to 3 times more effective than average software engineers, and that 10x and t

I read somewhere a report that suggested that top software engineers tend to be up to 3 times more effective than average software engineers, and that 10x and the like is only really achievable in comparison to the worst engineers, and the worst engineers are often so bad that it's not sensible to compare with them. For a company, avoiding those guys is probably even more important than hiring the best - if your company has 10x engineers, your recruitment process is probably broken. I have worked with some extremely productive software engineers. They tended to know the domain and codebase they were working in well, worked long hours and had either the enthusiasm, motivation or mental practice to maintain focus, and I believe those factors explained the majority of their advantage, which was large but not superhuman. But like the author of this article, I've also seen a lot of situations where an apparently huge multiplier was best explained in some other way. For example, some apparently 10x engineers were only so because they were allowed to only work on interesting, relatively easy early stage work. The difficult, fiddly work of mopping up the awkward corners was left to other engineers, who were considered 'slow'. Incidentally a lot of people will be a lot more productive if you let them work on only projects that interest them. I know some people who were considered 'problem' engineers because they spent most of their time doing stuff other than what they were asked to do, but they made a lot of interesting and useful stuff and with only a slight change in perspective or luck, they could have been considered 10x developers. For maximum impact, having the wisdom and opportunity to work on the right thing is much more important than working 10x as hard.

bluefirebrand 6y ago
> worked long hours This is interesting to me. Of course from a business perspective you want to prefer developers who are willing to put in big amounts of OT. But when it comes to judging their productivity, is it really fair to compare them to your devs who don't put in OT? As far as their performance review, maybe sure. As far as their actual skill and effectiveness? It seems unreasonable. A dev dev who works twice as much as an average dev is not suddenly equivalent to an average dev because the work they are producing is probably not that great.
- kybernetikos 6y ago
  Yeah, I was nervous putting that in there, because I think beyond a certain level, long hours start to tell in other ways. Some of the people I'm thinking of were contractors and would take months off at a time when they weren't working super hard. Some of them simply allowed their work to take up an unreasonable portion of their life, which then sometimes had negative effects on health down the road. I've also seen multiple times when '10x' engineers did a crazy hack working late into the night, which was lauded by managers, but actually had to be entirely rewritten over much longer by less lauded engineers. Lack of sleep probably impedes coding ability as much as alcohol (and that's another factor I've seen create big chunks of code that needed to be rewritten).
anjakefala 6y ago
> For example, some apparently 10x engineers were only so because they were allowed to only work on interesting, relatively easy early stage work. The difficult, fiddly work of mopping up the awkward corners was left to other engineers, who were considered 'slow'. I am someone who loves mopping up the awkward corner cases. For me, this is the most fun part of coding. I think the early design and infrastructure work is actually pretty challenging work. The decisions made at this stage pay dividends later on, in ease of debugging, api goodness, future expendability, etc. I prefer collaborating with senior engineers who are strong and relatively fast with that, and then I help clean-up to facilitate their speed. If everyone is on-board, I am not sure what is wrong with this arrangement.
- kybernetikos 6y ago
  > If everyone is on-board, I am not sure what is wrong with this arrangement. I think that insufficient attention is paid in hiring to building a team of people whose interests compliment each other. The situation you describe is fantastic. Problems would arise only if you and the senior were compared on speed for what are actually two very different kinds of work.
  - Viliam1234 6y ago
    I believe the "full-stack developer" meme did a lot of harm here. It is hard to discuss different strengths of different people openly, when everyone pretends they understand everything equally, because admitting that you specialize on X and can only do mediocre work in Y makes you seem like a loser compared to people who pretend to be great at everything. I have seen people happy when the database guy was allowed to design the database, the back-end guy was allowed to write back end, the front-end guy was allowed to write front end, and the CSS guy wrote the CSS. Then management intervened and said no, the highest priority task must be done immediately, by the first person available. Afterwards both the happiness levels and the code quality returned to the mean.

bluefirebrand 6y ago

> worked long hours This is interesting to me. Of course from a business perspective you want to prefer developers who are willing to put in big amounts of OT. But when it comes to judging their productivity, is it really fair to compare them to your devs who don't put in OT? As far as their performance review, maybe sure. As far as their actual skill and effectiveness? It seems unreasonable. A dev dev who works twice as much as an average dev is not suddenly equivalent to an average dev because the work they are producing is probably not that great.

kybernetikos 6y ago
Yeah, I was nervous putting that in there, because I think beyond a certain level, long hours start to tell in other ways. Some of the people I'm thinking of were contractors and would take months off at a time when they weren't working super hard. Some of them simply allowed their work to take up an unreasonable portion of their life, which then sometimes had negative effects on health down the road. I've also seen multiple times when '10x' engineers did a crazy hack working late into the night, which was lauded by managers, but actually had to be entirely rewritten over much longer by less lauded engineers. Lack of sleep probably impedes coding ability as much as alcohol (and that's another factor I've seen create big chunks of code that needed to be rewritten).

anjakefala 6y ago

> For example, some apparently 10x engineers were only so because they were allowed to only work on interesting, relatively easy early stage work. The difficult, fiddly work of mopping up the awkward corners was left to other engineers, who were considered 'slow'. I am someone who loves mopping up the awkward corner cases. For me, this is the most fun part of coding. I think the early design and infrastructure work is actually pretty challenging work. The decisions made at this stage pay dividends later on, in ease of debugging, api goodness, future expendability, etc. I prefer collaborating with senior engineers who are strong and relatively fast with that, and then I help clean-up to facilitate their speed. If everyone is on-board, I am not sure what is wrong with this arrangement.

kybernetikos 6y ago
> If everyone is on-board, I am not sure what is wrong with this arrangement. I think that insufficient attention is paid in hiring to building a team of people whose interests compliment each other. The situation you describe is fantastic. Problems would arise only if you and the senior were compared on speed for what are actually two very different kinds of work.
- Viliam1234 6y ago
  I believe the "full-stack developer" meme did a lot of harm here. It is hard to discuss different strengths of different people openly, when everyone pretends they understand everything equally, because admitting that you specialize on X and can only do mediocre work in Y makes you seem like a loser compared to people who pretend to be great at everything. I have seen people happy when the database guy was allowed to design the database, the back-end guy was allowed to write back end, the front-end guy was allowed to write front end, and the CSS guy wrote the CSS. Then management intervened and said no, the highest priority task must be done immediately, by the first person available. Afterwards both the happiness levels and the code quality returned to the mean.