Improve developer ergonomics. Standardize the boring parts of your projects. Simplify code. Fix flaky tests and flaky automation.
Keep a calm, steady frame of mind, so you have a more uniform appreciation of time passing. Don't fall into a busy frenzy or a puzzle-solving trance that allows a haphazard or complicated way of doing things to feel quicker than it really is. Don't let boredom blind you to the virtues of smooth, simple things.
A common mistake people make is identifying boring, predictable tasks as the most urgent focus for improvement. This is misguided. A task that is boring and predictable is already well-engineered. It can and should be further improved by automation, but much bigger gains come from standardizing the tasks that seem to go differently every time, the tasks that are typically handled by the most experienced developers. Making an "interesting" task boring saves much more effort than the subsequent step of automating it.
First, I agree. Second, I don't know if I would call it a mistake as much as non-optimal.
I would say that getting the boring & predictable ones out of the way frees you from keeping them in mind. This allows you to address the ones that "go different every time" without keeping track of the details.
Removing the boring/predictable stuff also means you can enter flow much more quickly (and regularly). I find that for me programming is more of a psychological game than a technical one. The ability to quickly get into flow is of very high value to me. However, in other domains and with other people "standardizing" the "offbeat" task may yield greater productivity gains.
TDD or other approaches which shorten the feedback loop, a bit of planning, selecting a task-appropriate language and task-appropriate libraries (either standard to the language or external), frequent refactoring.
Don't spend a manic day writing 10k lines of code and only compiling it at the end of the day. Don't go in without a plan and develop the structure in an ad hoc fashion. Don't delay refactoring until after the first 100k lines are written. Ideally never even write 100k lines because you've selected an appropriate language and libraries to let you write something that closely matches the problem domain.
Use templates/frameworks where possible for common activities. These don't even need to be heavy weight, but relates back to using libraries. If you're making your 100th CRUD site in some language and you don't already have a default structure, you're doing it the hard way.
Especially how do you avoid trying to boil the ocean while trying to "do easy"? I feel you could spend a lifetime to get truly comfortable, to not get constantly hit by small snags and papercuts.
