>Odds are far better than good that your high performers are achieving what appears to be high levels of productivity by building technical debt into the application by taking shortcuts whether intentionally or unintentionally. Examples of shortcuts are not taking the time to design and architect things well at all levels (low to high — think objects and object hierarchies, database schema changes, etc.), failing to test adequately, and crafting code that is hard to read, maintain and extend.
I've seen this: young developers who get things done quickly, but when you look closely at it, it's not really well architected and ends up needing a lot of fixes and changes. And worse, as said here, it's hard to read and maintain, and seems to have almost no commenting so it's very hard to understand quickly what's going on when you're not familiar with that code.
Lots of code is write-once, and in that situation productivity at the cost of technical debt is absolutely the right decision. There's no easy right answer.
I disagree. It doesn't take any real time to write a comment while you're thinking of it; coding for work is not a speed contest where seconds count, and if you're trying to save 60 seconds not writing comments, you're doing something wrong.
Most likely, people who don't comment have the exact same mentality you have ("this is write-once, no one's going to look at it"), but the problem is they're wrong. Other people do come back and need to change it later.
I've seen this: young developers who get things done quickly, but when you look closely at it, it's not really well architected and ends up needing a lot of fixes and changes. And worse, as said here, it's hard to read and maintain, and seems to have almost no commenting so it's very hard to understand quickly what's going on when you're not familiar with that code.