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.
I help a lot of people in a given week, and my browser tabs are out of control. What has helped a lot for me is opening all of the tabs for a particular issue in a new window, and often putting them as the only thing on my smallest monitor is a decent compromise for not losing it. Once I minimize that window it gets lost quickly, which also contributes to the tabs problem. Still need to solve that issue.
To a lesser extent, the smart location bar for Firefox at least will tell you if you already have that url open elsewhere, which saves me from abandoned/divergent wiki edits and lost workflows. Not always, but routinely for sure. It also can search your bookmarks, so tagging things with the name you think they should have helps a lot there. Now if I could just get better at deleting malformed urls from my history...
Except for the single window piece, these aren't exactly 'mis-en-place'. They're more second-order effects, akin to putting the common ingredients on the "right" shelf, so you can grab them quicker. The invisible ingredient in 'mis-en-place' is your head. If that's a mess at the beginning of the task then everything will be off. So you can 'mis' all you want but if you run an obstacle course to get there it's going to help but not as much as it could. Like showing up to a race tired.
Perhaps you can make use of the "save / restore / share" tabs feature of Histre: https://histre.com/features/save-restore-tabs/ (It is mine). You can also take notes on them, highlight snippets on the websites etc.
The biggest benefit for me is that it lets me put everything away without the anxiety of losing anything.
Here is a recent video that I made: https://www.youtube.com/watch?v=CQEs51fcbw0 (take one of the video; it needs to be seriously polished, but hopefully it shows a small part of how Histre is reimagining bookmarks to be your personal knowledge graph)
Tree Style Tabs in Firefox are a killer feature to me. They allow to group and structure dependent tabs, and quickly collapse or close entire groups unrelated to the task at hand.
Also, typing % and then some text on the search bar allows to find a tab if you remember its name. But I use an extension that does a similar thing but shows multiple matching tabs and allows to close duplicates right from the list.
Many tabs mean much RAM use. Auto Tab Discard is essential to make a hundred or two tabs manageable.
I would recommend Simple Tab Groups [1] for Firefox. Then you can have as many sets of tabs you want (with detailed names), that are backed up in case of crashes etc. They are also out of the way when you don't need them, no managing multiple windows. Easy to delete groups, or keep them for later.
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.