Hacker News new | ask | show | jobs
by jerf 2551 days ago
"I also believe that the idea of the 10x developer while not a myth, is so rare it’s not worth trying to find for most companies"

The problem with the 10x myth is that it assumes a single dimension of productivity, and that no-one is ever negative so there's some sort of sensible, positive "minimum" to talk about.

Senior developer leads a team of three other medium-experience developer, and completes the project in six months. Junior developer leads a team of 5 other even more junior developers, after six months they've got nearly nothing, so we pull in another 4 semi-skilled developers and 2 contractors who are drowned under the mess and don't know what to do, and six months later, the project is cancelled entirely.

How many times better is the senior developer?

There's nothing even remotely skewed about those numbers, either. Both are totally realistic. And yes, senior engineer can fail, and junior engineer could succeed. (Although the range of projects where a junior can succeed and a senior can fail assuming adequate initial knowledgebase for both is fairly narrow; generally if you find one, you've probably got a strawmanned "senior" engineer who isn't actually senior but just a collection of stereotypes in your head.)

If you're still offended:

A generally senior software engineer who knows nothing about the domain and his team of three develop furiously for a year and eventually deliver the first iteration of what was asked for, with another year to go on the project to finish it. A generally software junior engineer who is deeply familiar with the problem domain listens to the customer's problem and after a day's thought realizes what they really need is a very different, but also much simpler, solution, which they deliver in two weeks by themselves. How many more times valuable is the latter?

(I've actually advised someone like that in the construction industry. They were switching into a programming career in their 40s. I said, look, there's no realistic chance you're going to outprogram me in a really academic, isolated sense of the term. But you've got contacts, the ability to pass the shit test with other people in your industry which I and/or generic software engineer have no chance of, and a deep understanding of the problem domain. Don't worry about trying to outprogram a 20-years-experienced software engineer, take advantage of the facts that you know what your customers really need, and... you're there! and I (standing in for generic software engineers) am not! Life's about playing what you're dealt, but people are generally dealt more cards than they realize, I think. Not necessarily better cards, but they have more cards than they think.)

I tend to agree there isn't a such thing as an engineer who is 10x more productive than another, in the sense that they will do the same thing as that other engineer, just 10 times faster. The key comes from doing things differently, most of the time.

There's other differences as well, such as being aware of the pitfalls. I recently got myself put in charge of a billing system, and as a senior engineer, I at least have the good sense to be suitably terrified, for instance. "Move fast and break things" has its place, but "careful, paranoid engineering" does too. Almost by definition, your really junior employees don't really know how to do the latter. (They'll often be able to cargo cult it, which can be a start, but they won't really understand it.)

3 comments

My statement was referring specifically to an "individual contributor" and I said as much in the original post. If you are a team lead, by definition you aren't just an "individual contributor" and you're also not the "10x developer". Your increased effectiveness is because you have a team under you and you are a "force multiplier".

but "careful, paranoid engineering" does too. Almost by definition, your really junior employees don't really know how to do the latter. (They'll often be able to cargo cult it, which can be a start, but they won't really understand it.)

I also specifically said the difference between someone with 10 years of experience and someone with 20 years experience. If you have 10 years of experience -- you hopefully aren't a "really junior employee".

I've worked with a 10x developer. He wasn't a team lead because he wasn't interested in being a team lead and also probably wouldn't have been nearly as good at it as the person who was.

But man, was he ever transformative. Not only in terms of handling the most technically challenging tasks and solving the black-magic challenges that nobody else wanted to touch, knowing the C standard like the back of his hand, and getting things done quickly to a high standard of quality. He also was a force multiplier, because he would help others debug their problems when they got stuck and get them back on their feet and productive again, give advice for how to best handle various edge cases, and designed and maintained our tooling. He was a mentor to junior members of the team, and the team lead would ask his input and advice for how long things might take, what risks he could see causing delays, etc.

You can't plan around having someone like that but they make a world of difference if you're lucky enough to work alongside one.

Likewise. To have someone with immaculate technical judgment means you potentially have a custodian that keeps an entire multi-team codebase on track.
My apologies, that's a fair defense.

I suppose I so deeply agreed with you I went total mental blindspot on the idea that someone could be a 20 years skilled software engineer and not be (technically, if not necessarily managerially) leading at least a small technical team. I'm not going to delete my post because I think it still has interesting stuff in it, but I do apologize for my tone of disagreement.

On that basis I’d consider the junior to actually be more senior, as understanding the need of the user and building that is vital to the role. A senior engineer who churns out code without taking that step to understand the domain and build the right thing is not, in my estimation, senior at all.

Bashing at something until it finally works is, to me, something we do as beginners when we’re still in the mindset of solving every problem with code.

You'd be very surprised then at how fast some people at companies bang out code with very little understanding of the problem, get it done fast, and look like heroes because it works. They then build up an expectation of getting things done fast because "time is money" and end up with a garbled mess of spaghetti code that functions.

Most senior developers that I know are so good at the above that very little communication is required about even the problem. So in reality, they end up sacrificing the team and becoming one man armies.

This goes on until retirement, and then a junior replaces them because they're cheaper and they're stuck with trying to learn a huge ball of code on their own, because teams became obsolete and documentation was an after-thought, that could have been done with a bit more effort on the senior developer to get out of their box and actually impart knowledge.

However, there is the opposite end of the spectrum where they write great code and could do everything themselves while still knowing crap about the problem domain. At that point though, does the PD really matter? Most people , including customers, just accept code results on their face anyways.

You'd be very surprised then at how fast some people at companies bang out code with very little understanding of the problem, get it done fast, and look like heroes because it works. They then build up an expectation of getting things done fast because "time is money" and end up with a garbled mess of spaghetti code that functions.

And honestly, experience tells you when that's okay. If you work for a venture backed company where the owners and founders only goal is to get something up and running to convince investors to give them money or to survive long enough to go public (statistically unlikely) or to get acquired, the goal isn't to make good code that can be maintained long term. They don't care if the whole business is built on a house of cards that will fall as soon as they get acquired.

Too many employees drink the kool-aid and think the owners are interested in anything else except for an exit strategy.

"Great code" rarely gets someone promoted or recognized.

In my experience in industry, the developers are seldom if ever allowed access to what the client actually wants. That's what the po or product manager/ba are for. This is the reason I have come to loathe software development.

    > The problem with the 10x myth is that it assumes a single dimension of productivity...
There's another problem with "10x": people evolve.

No one starts their career as a 10x-er, juniors are not juniors forever and people take time to find their knowledge, preferences, the right context, employer, coworkers, etc, before they can even discover their "super-powers".

And anyway, all the people I've ever met who could be called "10x" would immediately reject that label and/or buffer it with generous praise of the team in which they work. They would also tell a LONG story of how they got to where they are-- hint: it never starts with being at the top of their game. Instead, it always starts with or involves a lucky-break or a hard situation made better by someone who believed in them.

If I consider myself even twice as good as average with something, it’s probably time for me to transition to something else and start over.

Right now, for instance, I’m getting into the $cool_kids front end stack and I am barely above the level of “don’t eat the chalk”.