It is no single change that can rocket our productivity. It is a change in the rate of change.
There are two outputs of everything we write: some code, and a new version of ourselves. If we stop thinking of our product as the code, and focus also on improving ourselves with everything we write, then we increase our own productivity in all future code. Then our abilities grow with compound interest.
The other day, I asserted that our code should be concrete, because it is more clear and maintainable. Daniel Spiewak argued, abstract early! This policy has benefited him: once he has formed the abstraction, then the next time a seemingly disparate requirement comes up that he can boil down to the same abstraction, he can tell immediately and without experimentation what problems are inside.
He was right, because what we do in ourselves is more valuable than what we do in the code. So what if that carefully abstracted code gets deleted two days later? The patterns created in the brain pay off for the rest of his life. And he can build to higher-level abstractions he'd never reach without that investment.
I've lived this payoff in another way: when I start a job, I'm less productive than other new developers are for 2-4 months. They want to jump right in and be productive. They're focused on their current code output. I want to understand the system, so I ask a ton of questions and dig around in the code to find the root cause of problems. This makes me slower at first, but by 6 months in, I'm one of the most productive people on the whole team, and still improving. The code we write pays off today, but learning pays off every day for the rest of our career.
It's the difference between building wheels, and building a machine that can make wheels. When we keep improving the builder of the machine, then production accelerates. From position to velocity to acceleration: raise the second derivative and the limit is infinity.
Trivial example: today, git merge came back with a pile of conflicts. I flipped through git documentation and asked a friend, learning about git's concepts of file status. This cost twenty minutes today, and it makes all future dealings with merge conflicts a bit easier. Now I know that git status -s will give me a grep-friendly summary.
Daniel is right -- spending time on code that never deploys to production is wasteful only if we learn nothing while writing it. The silver pill is: time spent coding is wasted if we learn nothing from it. The return value of our day is the self we become for the next day, while code is a handy side effect.