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.
This may seem obsessive-compulsive to others but the way I work on the computer, I close everything that I’m not immediately working on. No extra tabs, no bystander applications. I keep my desktop completely plain so that the only files I see are the ones I just produced/downloaded.
I would rather go through the pain of reopening apps/websites than to have it lingering when I don’t need it right then.
I don’t understand how people can have multiple windows of multiple browsers with multiple tabs open about things they aren’t working on while they work. The visual clutter overwhelms me quickly.
I almost physically cringe when for example I see people searching for the super important cost estimation of a project and finding it as “/Documents/documents/docs/Old Stuff/work/New Folder (1)/Amy/work/migration/temp18/excel/team/DO NOT DELETE/e.xlsx”
I think I obtain a lot of the benefits of focus without quite being this extreme. I use a lot of virtual desktops. One virtual desktop per logical activity. For example as a student it would be one desktop per course I'm studying. As a software engineer, each git-repo that I touch gets its own virtual desktop (especially when one application involves many git repos). Each virtual desktop has its own editor process, terminal, and browser window for documentation and tabs related to that activity only. This means I can change my focus just by switching to another virtual desktop. And the tabs and editors and such on other desktops are not visible (they are not even in the panel) while I'm not working on them. So unlike you, I have lots of bystander applications, and each one is exactly where I left it. They just aren't visible until I switch to that activity. So I would argue that they don't distract me at all.
I also have things set up so that there is a keystroke that raises the editor on the current desktop to the top. Another for the browser and another for the terminal. When I switch to another desktop, the same keystroke raises a different editor process for that desktop, etc. So within a desktop, I switch between these apps using the same keystrokes regardless of which desktop I am on. And there is only one way to switch desktop. I can't switch to another desktop via choosing another application on another desktop, because the other applications that are not on the current desktop are completely invisible.
When I'm working on something with a Scala backend, an Elm frontend, and C/C++ embedded device, and when I need to go back and forth often between these sub-applications making related changes, I can't afford to close and reopen each one when I change the language/repo. I can change desktops very often this way. eg. Add a new field to the frontend. Immediately add it to the backend and the embedded also. But they are in different repos. etc. etc.
If I have one editor opening all three projects it is a nightmare to navigate between files. But one editor for each language and repo is the sweet spot for me. And it means my documentation for Elm is all in a separate browser window from my documentation for Scala (which is on another desktop) etc etc.
Sorry this was so long, but I think all the details add up to making it an efficient system.
Yes! I started a very similar process just this week.
Some of us have no choice but to multitask. I just learned about multiple desktops in Mac OS X and using something very similar to what you just described.
Each desktop gets its own browser window, emacs frame, Iterm window and a sticky. Sticky says what was the last thing I did and what is next. So context switching is easier.
I keep Outlook and Slack on a second monitor always visible. So far I am liking it. I am dreading the inevitable reboot.
I also wish Apple supported renaming the virtual desktops.
I do the same thing. I think it's why I've ended up in a primarily terminal based environment. Tmux, Vim, and Zsh and a couple web browsers and I'm good to go. Very little clutter.
I also like to go through and clear house when I have several tabs open.
> I don’t understand how people can have multiple windows of multiple browsers with multiple tabs open about things they aren’t working on while they work. The visual clutter overwhelms me quickly.
Well, multitasking was all the rage not so long ago. A lot of people got bombarded with blog posts and articles about it.
I think this is a good example of the analogy falling apart. A feature that is 99% done may actually be fine. Or it may not be much better than 0% or 50% - that sort of depends on the business side and how incremental a given feature can be and still provide value.
Still, I think in general it's a good idea to be a little more on the "finishing mindset" of things than the "if it builds, it ships" side of things.
> I think this is a good example of the analogy falling apart.
No, it is not.
It is up to you to define what is 100% of your project. If you think something is not worth it, just don't put it in the 100%. Be honest in saying "No, we are not going to do it".
Too many projects linger because there is no will of getting this or that done. Either redefine the project or just f-n do it and be done with it. This helps put definitive end to the project possibly letting you call success on it. It also frees up your mind to work on other stuff.
I take the comment that something that is 99% done in time may or may not not be 99% valuable.
Example: marathon race. If you stop at 99% of the way it’s like not having run at all.
Example: washing the dishes. 99% done is pretty useful
In software dev it’s often a mix of these.
If you need to fix a bug that makes it awful to impossible to use the feature as your last 1% then your current value is 0. The good news is sunk cost aside the last 1% gives you 100-1 value compared to other tasks so definitely finish that off.
If you are doing a task that has 10 discrete stages of feature sophistication the 99% done could mean 90% delivered.
This is why you should try to chunk projects into small iterative chunks that deliver value and do them one at a time until completion. Reality sometimes gets in the way but its a good goal.
When I say redefine the project I mean make an honest decision as to what needs to be completed and what needs not to be completed, and then just finish according to what has been decided.
Lingering work, unfinished projects, are damaging to team productivity. It is better to turn a page and focus on a new task rather than have a dozen of them 90% complete and still occupying everybody's attention.
I try to set explicit success criteria for any task I create (ie Jira ticket). The task is either done or not done and success criteria are reference.
But this is bit more difficult on scale of whole projects.
I agree with that. Project with vague names like “improve speed” or “make it look beautiful” can go on forever! It’s better they are broken into incremental projects “use bootstrap theme” which can be considered done and then if there is an opportunity to decide to stop working on this kind of work and switch to something else.
With software you are never done so you have to decide to be done!
This isn't my understand of what the parent commenter is trying to communicate. I think the point that they're trying to make is this:
A chef could originally decide that a dish is only complete if it is garnished with a terribly rare ingredient that costs an enormous amount of money; this would be analogous to a dev team lead deciding that a new feature will only be considered complete if it covers non-primary use cases or specific pieces of functionality that will add a substantial amount of time to the overall development estimate.
The parent comment is saying that defining that 100% is part of what will impact your possibility/rate of success or failure; the 100% is not predefined or intrinsic, it's a place in time / level of progress that you need to carefully define. If rarity and cost keep you from obtaining the "finishing" ingredient 80% of the time that you make the dish then you're setting yourself up for failure. If you define the feature as only being finished when it covers nearly every sub-feature you can think of then you're setting yourself up for failure.
There also seem to be analogies between quantity and quality. You can get 80% of the way through a feature and decide it's "good enough". The leftover 20% could either be bugs that needed to be fixed or additional features. I don't think leaving out some additional features would be considered skipping the "finishing" phase, but leaving serious unresolved bugs almost definitely would be. An undercooked dish is nearly useless, but one missing a garnish is not.
Yes, I think this "99% counts for nothing" mindset is fair when applied to a task card or pull request. You can play games with semantics and say the journey is all that matters or it's the friends we made along the way, but seriously you can fall into a trap of having 12 unfinished feature branches, at which point most of them are practically guaranteed to go in the trash can. There's value in saying, that's really important, but it's more important to ship this first.
It is.
You don’t choose the requirements, your customers choose them like the customers in a restaurant choose a dish from the menu.
The analogy seems pretty broken, it doesn’t really make sense for several reasons that are written in the other comments.
I think they're talking about unfinished, undelivered tasks. A feature that is 99% done but only lives on your dev branch isn't delivering any value, it's just adding cognitive load as another thing you need to think about, try to remember, worry about forgetting. It's the same concept they're trying to push about inbox zero and only looking at an email once.
I think the next paragraphs clarify a bit.
> Finishing actions clear the mind – a finished plate does not require ongoing attention or memory. In contrast, when unfinished tasks are allowed to accumulate, they clutter the mind and make even the task you’re focused on difficult to complete.
> The same situation applies to knowledge work. It seems harmless to start and stop tasks as new information becomes available. But there is a hidden cost each time we do so. The unfinished task has to be managed and tracked and updated. It takes up space on your to-do list, on your computer or desk, and most importantly of all, in your subconscious mind.
> These small frictions, multiplied by every unfinished task and accumulated over time, can eventually add up to an overwhelming burden that grinds your progress to a halt. You can actually reach the point where it takes all your bandwidth just to remember and track all the unfinished tasks, leaving no time left over to complete them. You have to run as hard as you can just to stand still.
I think this needs to be combined with breaking things down into as small a piece of work as possible. Yes a feature may be valuable at 99% completion, but hopefully that means a whole stack of work items at 100% and a small handful of unstarted work items.
The whole point of knowledge work is that you are doing things that have not been done before. If they had, they would already be scaled or automated. In a chef analogy, you should be inventing new dishes, not running a meal service.
A chef running a meal service is supposed to cook a meal for every order that comes back to the kitchen. A knowledge worker is not supposed to handle every little request that comes their way. As a knowledge worker, if you’re not disappointing some people, you are probably not doing your best.
If you are overwhelmed with tasks as a knowledge worker, the solution is not to seek greater efficiency in handling them. The solution is to do incredible work on the ones that actually matter, and half-ass or ignore the rest. If you’re not sure which is which, finding out is job #1.
People who efficiently do everything they are asked are rewarded with more asks. People who do great high-impact work are not held back because they dropped some emails along the way.
I’m not saying it’s bad to be efficient at processing email and tracking requests, I’m just saying it probably matters less than many people think, and almost certainly less than this article implies.
> The whole point of knowledge work is that you are doing things that have not been done before.
I don't think this is true, and treating this kind of work as a sort of magic does the profession a disservice. The details change, but the process of organizing and performing exploratory work can be standardized and improved.
In the chef analogy, even inventing new dishes can benefit from structure. I'll use painting as a different analogy. Painting a brand new scene is creative work, and you're doing things that haven't been done before. But most painters will start a major work by first creating a few lesser works to explore the theme. They might collect some references. They'll often sketch a guide on their canvas. They'll build the composition in multiple layers. They'll lay out their tools before they start. They benefit greatly from having routine and formula to fall back on, so all their cognitive load can go to the creative parts.
> If you are overwhelmed with tasks as a knowledge worker, the solution is not to seek greater efficiency in handling them. The solution is to do incredible work on the ones that actually matter, and half-ass or ignore the rest. If you’re not sure which is which, finding out is job #1.
> People who efficiently do everything they are asked are rewarded with more asks. People who do great high-impact work are not held back because they dropped some emails along the way.
I agree with you, but that's a different issue. Yes, I'd love to see a companion piece on work-life balance and managing and pushing back on expectations. Yes, "efficiency" often just means upper management is trying to squeeze more blood out of a stone.
No, that doesn't mean a professional shouldn't be thinking about improving their workflow. These improvements help you achieve your point:
> The solution is to do incredible work on the ones that actually matter, and half-ass or ignore the rest. If you’re not sure which is which, finding out is job #1.
The take home from the analogy is to follow a process where delegation and hierarchy is key for efficiency. This benefits all kinds of work. Delegation or setting the right roles in a team (where possible, or making it happen) is better than half-assing or trying to do everything. I don't think there's anything admirable in being unavailable or losing opportunities to complete work due to inefficiencies that can be avoided with a bit more trust distributed throughout a team.
For the vast majority of engineers, even writing high impact code means repeating the same request/db query/response dance, code pasting or ebuggin activity, and to be actually good and efficient at any of these means having done them plenty of times.
Even understanding novel problem domains requires a certain structured approach to research, talking with users, writing out thoughts, etc. All this certainly matches the analogy laid forward.
Smalltalk-80 had a fantastic work-management facility. I haven't checked lately but I think Squeak and Pharo Smalltalk environments still have it.
On the desktop of Smalltalk Virtual Image you can right-click and say "New Project". This open a new window, which you can resize as you wish. Right-clicking on that allows you to "Enter Project". When you do you see a new desktop into which you can open various tool-windows, browsers, debuggers etc. And you can open nested project-windows inside a project-desktop, as deep as you wish. You can exit a (sub-) project but the (sub-)project still remains in existence, with its window in the parent-project as the handle to it.
As you exit your Smalltalk session you typically choose to "Save Image" which means this tree of projects, each having its own state and set of windows, perhaps a debugger halted on a piece of code, are saved with it. (You will see them the next time you re-open that same saved Smalltalk image).
When you're working on something you often discover that to do this you must first do something else. No problem, open a new "project" window on your current Smalltalk (project-) desktop. Once that sub-task is done you can exit that project and close its window. But you can have multiple (nested) sub-tasks open at the same time.
The name "project" is not the best word for them I think, I think they should be called "tasks". Why does that matter? Because I think it's important to understand that this is not about Project Management. This is Task Management. Something in the spirit of mise-en-place perhaps. You could create a Smalltalk image with tree of "project windows" on it and share it with your co-workers. These sub-projects could describe the subtasks and allow you to record you progress in them, say for cooking a specific type of dinner.
Smalltalk "project-windows" are such a great idea I wonder why something like them does not exist in other environments. No doubt having a "Virtual Machine" whose state is easily saved is a requirement.
It doesn’t seem very helpful with modern workflows..
Usually you don’t work on several separate projects, you work on one project and you switch branches depending on the feature that you are working on.
You can easily merge in your current branch the changes from another branch.
With the subprojects workflow how can you import the changes of another subproject considering that you are probably in the middle of the debugging or something else?
Smalltalk-80 -like "sub desktop-projects" are for smaller scale changes than "feature branches". They are about implementing different parts of a "feature" when that requires changes into several sub-modules.
I think "Mise-en-place" is really a good metaphor for it because you can arrange every tool-window you need for a given sub-task in a context dedicated solely for that sub-task. It is like in a kitchen you would have a separate "desktop" for preparing the meat and a separate one for creating the salad. They would need different tools around them, for easy access right?
A good example is implementing a client-server feature.
In the parent-task-desktop you are implementing client-side code that requests something from the server and then does something with the response it gets form the server. But the needed server-side function is missing, you must implement it too. Open a sub-project-desktop for working on that server feature. Open any editors and browsers and test-sets and change-lists and debuggers and spec-documents in that server sub-desktop. You can have similar windows in the parent client-desktop but those are totally separate from the windows you have opened in your sub-task-desktops.
It is easy to switch between the two back and forth which is often needed because when you change something in the server-part you may need to make a corresponding change in the client-part as well.
Or you discover a bug which is not about what you are working on now, but you realize it is best to fix it before doing anything else. Open a sub-project-desktop for fixing it. When you're done you get back to the exact same work-environment you were in when you discovered the bug and realized you better fix it right away.
Sometimes I miss restaurant work. I sit in front of a computer all day in a quiet room, it's so completely different to be on a line at a busy restaurant. It's loud and dangerous and hot and chaotic. In many ways it's the opposite of being a sysadmin. I'm not sure my body could take that kind of work now, but I do think about trying it again from time to time.
I do like the concept of having Mise for us "knowledge workers" too.
I worked in kitchens and as a server pretty regularly from about ages 16 to 22. After several back-to-back busy shifts my joints would hurt until I got a day off. Even at 36 now as I start to feel stuff ache a little more often and a little more acutely, it was different then. It's easy to see how decades of that kind of work can really take a toll on your body.
I was a sysadmin for an on-site HPC cluster and this sounds familiar. Compared to a restaurant, it's probably less dangerous and chaotic but more loud and hot.
A better analogy for the "finishing mindset" would be that every running process takes RAM, and you can only have so much of it. This highlights the fact that finishing a task has a value regardless of the value of the task, because it frees resources that can be used for something else.
I think trying to stretch the analogy too much is detrimental to the whole article. For example the reminders: a post it on my screen will remind me at all time that I should do something, because the "default mode" of the post it is existing. The default mode of the digital is not existing. I need to boot my computer to have my to-do list app, or consult my phone, or open my notebook. This is not the case with a physical reminder (sure the notebook is physical, but it needs an action to remind you of something).
I think the physical is actually what's missing in this article.
Mise-en-place is also that you have your tools organized in front of you, having physical reminders and notes, can be helpful for the knowledge worker as well. Having "your" workspace in the office, or at home as well. I find that a huge issue with flexible workstations.
> There is no class in college on how to triage your email inbox, manage your agenda, or organize your computer files.
Small nitpick, having to organize your computer files is mostly a consequence of Windows having a terrible and ineffective search. I recently realized that I don't really need to organize stuff in folders on Linux since I use meaningful names when I store files, and search when I retrieve them. On Windows, the search is unusable, and thus I spend a lot of time making a hierarchy of categories with folders, which is a waste of time. To use the kitchen analogy, the first time you use a good search is like the first time you use a good knife. It changes the way you approach things. I eat way more vegetables since now cutting them isn't a pain.
How is search better on Linux? KDE's Baloo is worse than Windows Search; it's an unending trainwreck of failing to index files (whether names or contents) on some computers and going stale on other computers. Maybe GNOME's file indexing is better, I'm not sure. Do you use the (non-index-based) find and grep CLI commands? In that case you can install them on Windows too, or install fd/rg on both Windows and Linux.
> How is search better on Linux? KDE's Baloo is worse than Windows Search; it's an unending trainwreck of failing to index files (whether names or contents) on some computers and going stale on other computers. Maybe GNOME's file indexing is better, I'm not sure.
I use Gnome and it works well. I'd say it's how I expect a search to work, at least.
I think search could be even better with ways to index other informations. For example, search into the metadata of audio files. My dream is to have something as good as Google in its prime, but for my own files. I'm still thinking on how to reduce the need for the user to produce metadata. For now, the "best" we can usually do is try to give files descriptive names and then search for it, which is good but still very limited to how the web works for example.
> Do you use the (non-index-based) find and grep CLI commands? In that case you can install them on Windows too, or install fd/rg on both Windows and Linux.
There are also tools to replace the search on Windows, but most people will never install those. My comment was more general, about how lots of people have been trained to not rely on search because the basic search in their files is broken. Maybe a consequence of this is that people have a resistance to search, which would explain why so many of them have trouble using a search engine by themselves. It's also a waste of human time, an enormous one.
I think you just hit the nail on the head why I spend so much time storing and organising in onenote, I always thought it was because onenote search is good, it's not, it's because the system search is so poor.
Windows’ built-in file search becomes embarrassing once you’ve used Everything. Though Windows search does save me from having to trawl through settings/control panel.
I'm a big fan of the one-touch inbox zero flow, although the way I do it is slightly different.
I have four folders that I organize all incoming email into:
1. Requires Reply
2. Requires Action
3. Keep Eyes On
Anything that doesn't immediately fall into one of these categories gets archived. Any email newsletters are immediately unsubscribed from (with the exception of Ruby Weekly and Python Weekly).
I also use a lot of automated filters/rules for applying organizational labels to different emails.
I use @Action, @Bills, and @Waiting. It if takes less than 2 minutes, I do it immediately upon receipt. Otherwise it goes into the Action folder. I use @ in front of the folder name so it's at the top of my subfolder list.
The author would be surprised how variable and not at all standardized tasks such as welding a seam or putting in an IV are. Sometimes requirements and or regulations (organizational or governmental) create dramatically different practices.
I came to comment on this as well... there is an entire industrial workforce of CWIs(certified welding inspectors), who exist because welding a seam is not as easy as youtube would lead people to believe. It's easy to make it look correct, but it's the attributes of the weld you cannot see that make it safe/unsafe. Doing it correctly is not something you can learn from a book or listening to someone talk about...it's something you learn by doing it over, and over, and over, until it "feels" correct. The author may as well have included "performing a quadruple heart bypass" in their list of well-understood concepts.
A knowledge worker learns from repetition the "right way" to do things. Example rules like "document your work in a clear and concise manner" read a lot like "weld the seam from a consistent angle and with consistent fill material". Multiple people will follow those instructions, and you will end up with very different outcomes among the individuals doing the work. The sign of a well-seasoned craftsperson is that it "feels" right, and that only comes from long-term repetition.
Not a welder, but I'm aware of inspection procedures that use gauges to determine compliance with expected "shape" and consistency thereof. Also, x-ray imaging of welds and ultrasonic inspection of welds is a thing. You said "looks correct" and visual inspection is a thing but there are a lot of facets to that visual inspection that require some experience and tooling (e.g. magnifying glass, lighting, etc).
There are some useful ideas here that can be applied, but overall the analogy is deeply flawed.
Most programmers rarely spend the majority of their time on things that they have created before. Instead, most of the energy goes into understanding problems.
Cooking is just not very much like programming. The chef can see exactly what the ingredients are at all times and exactly what the state is. He is making the same dishes night in and night out. If he makes a mistake and overcooks something, it is a significant time waster. Its as much a performance as anything else.
Treating programming as if it were an exercise in extreme efficiency points to a misguided mindset. Like a feature mill with a clueless manager happily spewing out Jira tickets as fast as he can think of them, and some overworked outsourced staff in a sweaty room on the other side of the world cranking out features as quickly as possible with boilerplate-based code generation.
A very good read, and indeed "mise-en-place" is a skill / philosophy / system which can greatly assist knowledge workers if they apply it. Most chefs learn how when they apprentice under a master chef, and adopt or copy what they do. These skills are seldom learned by reading a book or from an essay, because they need to become habits to be effective.0p
The long term trend is toward ever more specialization. Even a "full stacker" implies a certain subset of web tech. You wouldn't hire a "full stacker" to do your kernel work, or device driver, or likely even your mobile app. 30 years ago, programmers was programmers.
There might be a momentary tick downward on this trend, like a correction in the stock market. But I don't think it changes the overall direction, and honestly I haven't even noticed a blip.
I feel like this is ridiculous idea with a book attached to it.
Happy to be wrong
But it reads like an advertorial
Like a politician blowing smoke up KWs asses
Look at this line:
"We approach each new task and project as if it was a completely blank slate, requiring an entirely new approach."
Wts?
Cmon, man.
Every other line is lionizing 'us' for our rugged good looks and ability to produce SUPERDUPERHIGHQUALITY ... something... in the face of almost insurmountable odds.
Its a self-parody.
Sorry. I'll pass.
But happy other folks find value in doing first the things that... need to be done first.
It's a repackaging of the trivium method (inputs, processing, outputs) where order of operations is key to success in manifesting the desired and ideal result. It applies to nearly all subjects.
There is a fantastic book called 'Work Clean: The Life-Changing Power of Mise-en-Place to Organize Your Life, Work and Mind' by Dan Charnas that goes into more depth about Mise-en-Place.
Somewhat of a shower thought: the intern system at a large company oftentimes selects out people who cannot afford to even be interns, thus causing the class gap to be widen; the apprentice function of trades very much does not.
That may be true in industries that require wealthy clients (e.g. art galleries) but in computing (and the unionized trades) interns /apprentices are paid.
I am absolutely specifically thinking of unpaid internships in the tech/startup industry. Trades are an example of getting paid as a journeyman, while doing useful work for the company from day 1.
I've interned at an art gallery. I didn't mind getting paid, as I was also getting course credit (and the work wasn't all that hard anyways). But the art was sold on consignment - NO ONE got paid unless the art moved off the walls, and if I did sell a piece, I got a commission for that. But I wasn't interning for a future career working in an art gallery, I was interning as an artist.
The art world is its own special type of hell for those who aren't super wealthy. To sell items that intrinsically have no utility is a pretty weird business. The unpaid intern that's watching a gallery while doing their coursework on a Thursday afternoon while no one comes in is the least of its problems.
> Trades are an example of getting paid as a journeyman
You’re correct in that trades people do get paid while working. However, to add some nuance, I think the rate is going to depend on the trade, company, location, education completed, and work hours completed.
My brothers have their red seal and work as tradesmen. It’s 40-50% of the journeyman rate for 1st years. There are 4 years of schooling and something like 2,000 hours of work required between each level of schooling (there is a tolerance to early start / late start). Wages increase when the apprentice hits specific hours worked milestones or school level completion milestones.
This applies to BC, Canada. As I said before, this may depend on location, so it may not be the same where you are.
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.