Hacker News Reader

Comment by phendrenad2 | Hacker News Reader

I've never met a 10x engineer. (Does that make me the 10x engineer? I doubt it).

Personally I believe that the myth of the 10x engineer comes from the very real and very visible fact that often times, one engineer will be 10x as productive as someone sitting in the next desk over. Why is this? There are numerous factors, and certainly innate skill and programming practice come into play. But I think that only gets you to, at maximum, 2x the average. To get to the perceived "10x" you need luck, the right mindset, and a the buy-in from management to push others aside and take on the most juicy projects (which is self-reinforcing once management sees you as a "10x engineer"). "Stealing the Corner Office" is a good book on such tactics (although it ostensibly applies to middle-managers).

View on HN

I have and I'm sure others here have too. It's usually people who are not only skilled coders but are capable of staying ultra focused for longer hours. Go check you favorite team project on github and open the list of contributors, notice anything?

Remember it's 10 times better than the worst not average programmer. On average a 10x would be 2.5 better than average. If you think you are average or slightly above average a 10x programmer would look like a 2x to you.

I have seen a very clean example of this once -- we hired two people at about the same time, let's call them A and B. Both had about the same years of experience and worked on similar technologies in the past. Neither was familiar with our codebase. Both got the same onboarding process (1-on-1 with experienced developers few times a week, simple tasks). Then both could choose tasks to work on from the same pool.

Two month later, A is done multiple simple tasks and in the middle of refactoring a tricky module to add much needed functionality. B is still working on their second simple task.

I would not be able to quantify difference between them, but it could easily be more than 10x.

(We later tried to see if B would do better at other projects -- a different programming language, a project that needed a small program from scratch instead of modifying our huge main codebase, etc... None of that did help.)

I have managed a number of small to large software dev teams in my career. And there was always a small core of developers who outperformed the rest of the team. Not by working harder, but by working smarter: focusing on the right priorities, reducing complexity, automating things etc.

Nor have I, but I did work with someone who was regarded as such at a company I worked for. He got the reputation for shipping features fast, but everything he did was quick and dirty. This lead to some resentment with other developers tasked with extending the new features he shipped - invariably the simple extension to the feature would take longer than the original feature. Instead of indicating that everything this guy ships is a nightmare to work with, it further cemented the notion that this guy was a 10xer.

That's not really a 10x if they're doing a crappy job. I can close hundreds of bug tickets saying "not reproducible" without really trying, but that doesn't mean I was productive.

Reply on news.ycombinator.com