[umanwizard]

I suspect that the most important difference between great and typical engineers is that the great ones make a better product, not that they make it faster. If my hunch is correct, worrying about concepts like "10x" is missing the point.

[snoman]

I'm not saying anything about you here, but I feel like this is what a typical engineer would like to believe to make themselves feel better, but getting things done faster leaves more time for doing them better. Once you're at that stage, it's a simple matter of discipline.

[JimDabell]

> getting things done faster leaves more time for doing them better

It's the other way around. If you take the time to do things better, then you build up momentum and make future work easier. If you want to improve productivity, slow down and do things right, consistently. It'll pay off in the long run.

[collyw]

One example of this I see all the time. You need some new functionality, but altering database tables is a pain in the arse, compared to adding more code. So you add more code. Rinse repeat until you have an unwieldy mess of code. Changing the database model would have been more difficult initially but its often worth the effort.

[rimantas]

Doing thins faster leaves more space to do more thing faster, not making anything better. And that's how you end up with a pile of technical debt and impossible to change system.

[enraged_camel]

>>but getting things done faster leaves more time for doing them better.

I don't buy it. Sometimes you need to do things deliberately slowly in order to think everything through. All the use cases, the potential edge cases, failure modes, and so on.

IMO a "10x" programmer is someone who knows when to crank out code and when to take things slow.

[amazingman]

>getting things done faster leaves more time for doing them better

I'd love to believe that, but it assumes that the incoming rate of things to be done is and will remain lower than your sustainable velocity. In practice, that "more time for doing them better" has a significant chance of becoming additional technical debt.

[verinus]

hehe in my experience once it's done, it's done- no time to make it better as there is the next feature up waiting and the customer does not buy quality only "quantity" (of features,...)

[beambot]

Is your experience in consulting...?

[cle]

The answer is in between. The best engineers know how to balance speed with quality. Great engineers make good products, fast.

[ajuc]

If X introduces half as many bugs as Y, and finishes tasks as fast as Y, and debugging takes majority of time in the project - then X is moving the team forward many times faster than Y.