I started seeing the value of this ideology recently. I have a really strict routine before I write a single line of code on a complex issue. All of these ways of thinking ultimately came out of efficiency gains I learned on my own in the kitchen. Prepare, then work. Trying to prepare while you work is chaos (but sometimes essential).

The very first thing I do after finishing a design review narrative is to type up a list of discrete tasks that I plan to execute. These don't necessarily say what to do line-by-line, but draw out a very clear picture of what code areas are edited and what the dependency graphs look like. These also highlight specific configuration or other UX points to reference during testing. These task lists are specific enough that other developers could reliably execute them without any additional guidance.

Then, I take a short break and review my task list when I return. 9/10 times I find I want to tweak it a little bit.

After the final confirmation, I sent notification out to my team that I intend to execute the task listing so they have a super clear idea of what functionality to expect on the other side.

I have found that this reduces my anxiety/stress by orders of magnitude throughout the day. Starting with visual studio and fumbling around various parts of the code base might be a good way to get your brain warmed up in the morning, but its certainly not a rational way to go about solving a complex problem.

For trivial issues, production RCAs, etc., the process is certainly a little bit more streamlined than what I note above. This is more about how to do work on big tasks.