He also taught me the phrase "lazy man's load", in reference to trying to haul everything from the car to the house at once. Taking less each time reduced the risk of an accident (like dropping a bag of groceries or having the bottom tear out because it's not properly supported), even though it means more trips it (usually) produces the better result. Which also seems appropriate here, the lazy man's load is born of haste and is decidedly not the easy way in many, if not most, situations.
From the movie : "How fast can you take your time?"
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.
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.
XKCD made a comic about automating task -> https://xkcd.com/1205/
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.
I've been working in very tight spaces where I twist myself into pretzels trying to get at a particular spot, all while wrapped up in a homemade hazmat suit, to the point where I can hardly breath or see. It has gotten better after I established one rule: No Stress Positions. Meaning, do whatever it takes to get comfortable before proceeding.
Before, if my back would start to hurt from a difficult stance, I wouldn't really notice, I'd just speed up to try to get it done before my back gave out, frequently botching the job and cutting or scraping myself in the process. Now, I notice that I'm breaking The Rule, think about the topology, reposition myself, maybe add cushions, maybe spend some time to move things out of the way. Fixup my mask and goggles, and then take my time.
Before I'd only take notice of my discomfort on failure, when I just couldn't do it anymore. And that resulted in a strong desire to quit. Now I spend the effort to get myself in an "I could do this all day position", and I can do it all day. I think the same thing applies to washing dishes or making breakfast. First step, just notice that you aren't doing it in easy mode.
It's summed up by the old Two Bulls on a Hill joke.