Very interesting suggestions, all worth trying. Having a very capable coworker can help here, because they can show you what can be done in a short amount of time. Specifically I've noticed that some devs get "winded" by a change and want to take a break before moving on; others simply continue. This ability can be improved with practice, both within and across contexts. Doing things quickly is valuable for many intrinsic reasons that are often overlooked because we descry the poor extrinsic reasons. As with car repair, the odds that you forget how to reassemble the car scales with the time the repair takes. Similarly, if you can execute a feature in a day (especially a complex one that requires changes to many parts of a repo, and/or more than one repo) this is much less risky than taking many days or weeks. (To get there requires that you have firm command of your toolset in the same way a mechanic understands his tools, or a musician understands her instrument. It also requires that externalities be systematically smooth - I'm thinking particularly of a reliable, locally repeatable, fast CI/CD process.)<p>(The calculus here is a little different when you are doing something truly novel, as long periods of downtime are required for your brain to understand how the solution and the boundary conditions affect each other. But for creating variations of a known solution to known boundary conditions, speed is essential.)