[jeffbee]

I agree there's not a natural tension between quality and speed, but the speed part is really hard to measure. You must consider the time of all future readers and maintainers of the code you are writing. Spending time to write a test or comment today is an investment that pays back in future fast iteration. Saving time by skipping code review, dashing off weird and confusing interfaces or variable names without revisiting them in a second pass, that type of thing is the opposite: it can appear to save you time today, but is costing you future time.

[Jensson]

> Saving time by skipping code review, dashing off weird and confusing interfaces or variable names without revisiting them in a second pass, that type of thing is the opposite

Nobody here is saying you should do this, it is a strawman. Rather being fast means that you can revisit your interfaces 10 times rather than 2 times, spend more time thinking about your names, have more time to write tests, review everything several times before code review so no issues are found etc, ultimately producing much higher quality code.

It seems like you think this article is about "I write code quickly by not doing things properly", rather than "I practice to become faster".

[jeffbee]

I have no disagreements with the article at all. I only disagree with the idea that "doesn't understand the language/codebase/requirements" can only cause slowness. That condition is at least equally likely to cause the fast solution.

The real "10x programmers" I have known spend practically all of their time deleting and refactoring code. A handful of fake 10x'ers I have met in my career, who enjoyed a reputation of rapidly dashing off MVPs, were stone-cold idiots, one of whom wrecked an entire company with his 10x-ness.