Hacker News Reader

Comment by jmchuster | Hacker News Reader

If we're taking about is just output on a larger macro scale, then yes, hiring enough people will replace 10x engineers.

But some things i think you won't be able to replace --

You won't be able to replace speed on short-term projects. Lots of people means lots of communication overhead, which really kills fast responsive speed. If you value time to answer, you'd prefer a small team of really smart people instead of a large team of average people.

You won't be able to replace the insights. Tasks and knowledge are distributed amongst many individuals in bite-size chunks, so you miss out on insights you only get when someone holds everything in their head at once.

You won't be able to have a small team / small company culture anymore. You have to be large, standardized, bureaucratic, catering to the least common denominator. And then make up for it with volume.

View on HN

Just to give a concrete example: no amount of software engineers can be hired to produce comparable work of an expert cartoonist except by dumb luck. Throwing 1000 engineers won’t solve the problem.

I imagine within the tech world there are tasks that are ill defined and a small subset of engineers can solve, but a typical engineer may not have the background to solve it.

>no amount of software engineers can be hired to produce comparable work of an expert cartoonist except by dumb luck.

You actually hit this nail quite on the head with the example. The "10x engineers" get a lot of their "10x"-ness from creativity - most I've met are cartoonists, painters, musicians, writers, cooks - artists in general that love software as a way of expressing themselves and earning good money. The beautiful bits of code you get after are usually there because the starting point is "create it" not "implement existing solution/pattern".

This has helped me to understand this very problem (which I didn’t really know had a name)

Uh, you left out passionate lego builders (AFOL). I’m adding it for you.

I generally consider myself a 5x coder... I usually spend about 1/3 the day reading/learning and another 1/3 experimenting... only about 1/3 of a typical day will I be on-task, and usually still outpace my peers. This last 2-week cycle, I literally did all the assigned work, and refactored a few things that annoyed me in one caffeine fueled night.

I used to do design/graphix/ux work... that always interested me. Programming pays better, and I have a talent for it. I have spent time learning patterns, etc, but not through a formal education. I tend to just see a good way forward... creating discoverable code along the way. I find a lot of the time, the formal patterns tend to just make things more complicated than they need to be.

Just my own take on things. I'm kind of lazy in a good way. I have spurts where I will do a crazy amount in a short time, and those where I'm closer to coasting. Like many/most creative types, it varies.

> hiring enough people will replace 10x engineers

The math is not that simple. The output of a Junior engineer is much different from that of a Senior engineer. You can hire any number of Junior engineers you want, and they won't have the vision and seasoned experience of a Senior engineer for producing higher quality code with less technical debt.

Even among Senior engineers there are different grades of experience/competence/capability.

Cue the link to Mythical Man Month:

central theme is that "adding manpower to a late software project makes it later."

https://en.wikipedia.org/wiki/The_Mythical_Man-Month

I think its important to understand there are also relatively high floors to getting certain things done well. If the engineer is too junior or simply not good enough, its not that you will get there slower, its that you may not get there at all. Or you get there slowly and with a very buggy or unmaintainable mess. Some engineers can even go backwards in that sense, attempting to optimize the wrong solution and spending months on something that in honesty can't actually be completed.

I've had junior engineers outperforming senior engineers, even counting the hours I had to spend correcting and guiding.

Some engineers are just slow. I don't think it's much correlated with experience. If your goal was never to be a super productive programmer, I don't think you'll ever become one.

This might also be why there is this spectre of agism in the industry. Everyone knows there's greybeards out there that would eat your lunch and get paid the big bucks, but at the same time older programmers have hard times interviewing. At that age most of the really great programmers have probably already been fished out of the pond.

I think it depends... where I am now (third from last day), I'm one of the younger devs at 46yo. which is wild to me... about 2/4 of those here older than me have little interest in taking on new approaches or techniques. The other 1/4 absolutely work to stay current. Some are coasting to retirement, others of us don't ever plan to stop.

I will say, my recent stint of interviews over the past 6 weeks or so has been pretty painful. Everyone seems to be going through 6+ interview stages. The reality, even then, I'm not sure they're getting a great signal:noise outcome. Some of the tests are for things that will never be used for those jobs on any given day.

I do miss my 20's when an interview was maybe an hour and a half on an afternoon, and an offer shortly after.

It's crazy, I wonder if it actually works and they actually get a higher percentage of good coders. I just do a face to face, then a take home assignment, then another face to face where we discuss the take home, and then I immediately make the decision. I skip the take home if they've got impressive GitHub accounts or other clear public displays of skill.

The issue I seem to often see, for some reason, is that people who have a say in hiring often don't realize themselves that the great engineer did something quickly thanks to an insight, or, more generally speaking, thanks to being very good, or being able to turn the problem on its head, as opposed to pure brute force.

They often seem to have the idea that it's more or less grunt work. Yeah, if a truck will haul 10 tonnes in one go, you'll get the same time if you hire an army of people, each carrying 10 kg on their backs, give or take economies of scale.

There is a flip side to that as well I think. One 10x developer can be more productive than 10 developers, but often 10 10x developers cannot be as productive as 100 developers. Certain things just don't "scale out" with the sort of creative advantages that highly productive engineers use.

Overly complex code is more difficult to modify than elegant simple code. A 10x developer will produce simple elegant code. That is one reason why they are a 10x developer. Ten 10x developers will create a much more simple solution than 100 standard developers. Standard developers usually create a mess. That is what always happens, we have all seen it. So 10 10x will be much more productive than 100 standard developers.

Speed an accuracy are on different dimensions that are somewhat independent.

Another consideration is how much time we can afford for the solution to be wrong and need to be tweaked. For anything that has to work the first time, you want one (two, really) of your more sober and likely expensive engineers on the case, even if they aren't your fastest.

You may or may be able to replace your 10x engineer for this kind of work, but you're likely to be hamstrung by your interview processes.

Reply on news.ycombinator.com