Live data from Hacker News

Busting the 10x software engineer myth

swarmia.com

31–40 of 356 posts

Re: Busting the 10x software engineer myth

#31
post #3

I know "10x engineers" exist; some people are fakes and put forward things that look like they have high impact but are actually a bit shoddy. Some people like to be present and suck up. But some people really do just work hard, smart and have deep passion for what they're doing- and importantly: pride, which makes the quality of the content great too. Some of the best engineers I know "visit" bits of code or infrast…

> It's not a myth they exist, but you shouldn't depend on them.

It's hard to tell if it's arrogance or reluctance to admit some people are more valuable than others and just allow them to get to a point they prefer to leave than stay.

Domain knowledge, institutional knowledge, whatever you wanna call it, takes time to acquire and these kinds of companies are equally reluctant/arrogant to spend enough to hire properly. That's not enough to kill them mind you, not right away anyway, so they are destined to be mediocre at best I suppose.

Re: Busting the 10x software engineer myth

#32
I work in ML engineering, and I’ve seen people work on a problem for the better part of a year with little to show for it. The non-progress gets on leadership’s radar, so even more resources get directed to crack what should be a solvable but non-trivial problem.

An engineer who could have solved this problem without a fuss within a month or two is easily a 10x engineer. Not because they work 10x faster, but through better ideas and thought process, efficiency with their tools, and exercising leverage. This is even without considering their additional impact on the work of others.

I think this could be applicable in any software or tech field, as long as the best solution to a problem isn’t trivial or immediately obvious.

Re: Busting the 10x software engineer myth

#33
post #3

I know "10x engineers" exist; some people are fakes and put forward things that look like they have high impact but are actually a bit shoddy. Some people like to be present and suck up. But some people really do just work hard, smart and have deep passion for what they're doing- and importantly: pride, which makes the quality of the content great too. Some of the best engineers I know "visit" bits of code or infrast…

“Adding people to a late project makes it later”. Equally, replacing high performers with multiple people wouldn't work most of the time.

Yea funnily enough I just added a comment along these lines about restaurants in a different story. Just because an engineer is 10x better in some sense that another one, it doesn't meant that 10 of the lower quality engineers will make up for it, just as eating 10 times at McDonald's isn't going to be as much fun as eating once at a great restaurant (for most people)

Re: Busting the 10x software engineer myth

#36
post #27

Very sf-type of term, is it still in use? From an eu perspective the idea to rely on some members of your team to be 10 times more productive than others seems like a terrible idea for anything longer than a 1 month sprint. That's not to say people's raw smartness, competence and experiences are the same just that a better focus would be growing the team as a whole.

> From an eu perspective the idea to rely on some members of your team to be 10 times more productive than others seems like a terrible idea It's just less socially acceptable to say it out loud, doesn't make it any less true. If anything, 10 is a conservative estimation: the spectrum spans orders of magnitude. > a better focus would be growing the team as a whole Not mutually exclusive. Prima donna behavior is alway…

Strange that always the 10x is blamed for communication issues. The passive aggressive 1x, who try to undermine him, are a group and as such always right.

I haven't seen a true 10x who was still writing code and growing the team. Time does not permit that, it is a fantasy. There are team growing "10x" engineers who shamelessly take the credit for everything.

Re: Busting the 10x software engineer myth

#37
A fact I notice in a lot of teams and orgs, valid for both this and the 'heroes' discussion:

Every organisational silo has,in the long term, exactly one 10x engineer, a.k.a hero.

If there is no hero, the organisational silo will fail unless someone cares enough to take the role. If there is a hero, the need for a second one disappears. If a hero falls away, you'll have a few months of chaos after which a new hero appears.

People will naturally give problems and hard projects to the best available person, and generally people agree who that us. So one person with a slight edge gets all the training and quickly gets much better.

Heros are a consequence of organizational barriers.

Update: That last part is inexact. Heros are a consequence of knowledge barriers.

Re: Busting the 10x software engineer myth

#38
Why do you think Ari-Pekka believes it’s the organization of engineers that creates long-term sustainable productivity?

Hint: What does Ari-Pekka do for a living?

Most people want to believe that what they do is the unique secret sauce of value creation, and they want others to believe it too. This is basically what you call politics.

Re: Busting the 10x software engineer myth

#39
Well, my experience is that to increase productivity the most important thing is not doing things. If you can filter out the meaningless features and shut down products that are a product of politics (giving someone a product to keep them happy even though everyone thinks it useless) you can increase productivity much more than focusing on the technical aspects of development.

Re: Busting the 10x software engineer myth

#40
I know an objectively measured 500x engineer.

In the '90s, Siemens AG and Ericsson made a joint venture called Ellemtel for a classic six-month death-march project: if it completed on time, the customer paid. Otherwise, discarded. Each company sent 250 engineers.

At the end of the six months, they delivered a working system. Fully half the code in it was by this one engineer.

Post reply on HN