[marcusbuffett]

Yeah I'm also sick of seeing articles cite this mythical trade-off, where any increase in programming output must be correlated with being a bad team member, churning out bad code, and generally being a pain to work with.

Anyone that's worked with engineers can tell you that there are simply some people getting more done than others, in the same amount of time. Are there people producing bad code? Yes. But I don't think output is inversely correlated with code quality. In fact the people I've worked with that have the most output, also had some of the highest quality code. I've never experienced this mythological 10x rockstar figure that works alone creating impossible to maintain systems, and I've worked closely with dozens of engineers. He probably exists somewhere, but not with the sort of prevalence that justifies every programming productivity article ripping on his archetype.

[kgeist]

In our team's current project, the engineers who can be described as "10x engineers" are the slowest when it comes to delivery of features. They have been transferred to a legacy project with lacking tests, messy spaghetti code full of bugs. They spend a lot of time adding tests, refactoring the code to be more modular, removing various cruft. It looks like they are much slower than the previous mediocre engineers, and they produce a lot of code, but it pays off: while the userbase is increasing, our bug reports rate per month has decreased by 2x in a matter of 1.5 years. So I think the amount of code output is only part of the equation.

[earnesti]

If a system is impossible to maintain, that system is nothing of value, and therefore doesn't fit to any sensible definition of 10x.

I have always assumed that the 10x means value creation, not some kind of "lines of code" output or other nonsense. And for sure there are 10x programmers, maybe even 100x. I have been mostly working at startups and you see these early stage decisions and designs that create huge costs when the company starts to scale, similarly you have some decisions that might save huge amount of costs during the company life time, or allow better revenue generation etc.

[ownagefool]

> I've never experienced this mythological 10x rockstar figure that works alone creating impossible to maintain systems, and I've worked closely with dozens of engineers.

I've seen this plenty of times.

Recently I was trying to explain the pros and cons of micro-services, and more importantly, microrepos, with regards to automated testing. The lead engineer that said he'd quit if I colocated the tests with the app.

Same place, they replaced all deploy system with argo, but every environment is pinned against main, which means you can no longer test a change without it going to all environments at the same time.

In both cases, the engineers are actually much higher skilled than average and churn out / lead change, but they'd rather be chasing a fad and just don't care if their changes shit on other parts of the SDLC.

[earnesti]

That case sounds more like you being 0.1x developer about obsessing over test automation, where the 1x guy just didn't seem them to be worthwile.

Personally I have had clashes during my career with people who obsess about unit testing way too much in places where it just doesn't add any value (in fact destroys it by requiring lots of work and additional mainteinance). Value in the end is quite a subjective thing so it doesn't make sense to argue that much about it.