In many discussions about being a great engineer the focus is on how fast you write code, or build a system not the ability to pick the right thing to build.
This blog eloquently describes that the problem of picking what to not build is the key to productivity.
But how fair things are is the point. After all, it’s not like 10x the perceived productivity is very likely to give you 10x the compensation. So there’s not a whole lot of reasons to “cheat” and appear more productive than you are. The main reason to be productive is because there’s fire raging up one’s arse, more than any tangible benefit.
The point I do want to make is, to get more done, you don’t need to succeed more quickly (although that helps) as much as you need to fail less often. And not all failures are due to lack of knowledge or skill; most of them are due to quitting before something is actually usable – or due to there being few chances for it to be used in the first place.
So I believe, having authored a lot of code that went down the toilet, that you don’t get productive by working as much as by not working– not on stuff that is likely to get thrown away.