Mise-en-place for knowledge workers
fortelabs.co
fortelabs.co
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.
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.
[1] https://addons.mozilla.org/en-US/firefox/addon/simple-tab-gr...
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.
The biggest benefit for me is that it lets me put everything away without the anxiety of losing anything.
Here are some of the features: https://histre.com/features/
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)
I find it really frustrating that most solutions don't do this...
I actually read the book mentioned in the blog post. Here’s my “Mise-en-place” workflow:
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 think you have inspired me to go full on with it.
Well, multitasking was all the rage not so long ago. A lot of people got bombarded with blog posts and articles about it.
Checkout Amna, it might be able to help (https://getamna.com).
It minimizes those browser windows away, and you can focus one thing at a time
I also like to go through and clear house when I have several tabs open.
It's a very pleasant way to work.
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.
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.
For windows, this project is a great way to get keyboard shortcuts for desktop switching: https://github.com/yalibian/i3-windows
Often the old monitor has the TO DO list or a design so I'm reminded what I'm doing.
The main two windows usually have something like the following:
1. main file/documentation
2. main file/subclass data model
3. design file (e.g. DB schema)/requirements
4. tests/design file
5. main file/tests
Sometimes I do need a little more, so that's where the other monitors come in. But for the most part, one window one file helps.
Perfect is the enemy of Done.
It hurts me to read this and to think of people adopting a "finishing mindset" while also trying to get behind:
(1) planning is prime
(2) arranging spaces and perfecting movements
(3) cleaning as you go
(4) making first moves
(5) finishing actions
(6) slowing down to speed up
(7) call and callback
(8) open ears and eyes
(9) inspect and correct
(10) total utilization
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.
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.
This is why the analogy is shit. “Redefining the project” as done when it was 95% there is the same thing as it being good enough.
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.
I always thought it is rather common sense, borne from experience: https://en.wikipedia.org/wiki/Ninety%E2%80%93ninety_rule
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.
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.
With software you are never done so you have to decide to be done!
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.
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.
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.
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.
(Which I also completely agree with).
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.
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.
I do like the concept of having Mise for us "knowledge workers" too.
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.
People who have never worked in a busy restaurant probably underestimate the type of toll that work takes on your body. It can be grueling.
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).
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.
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.
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 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 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.
TLDR: x-rays, ultrasonic testing, and liquid penetration tests
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.
Heads up for the author that this skips #6, and goes from 5 to 7.
These days knowledge work seems to be about making everyone a "fullstacker".
I love learning but I think it is more than a bit wasteful to let me do css work (I have red/green colorblindness).
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.
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.
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.
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.
* Have only one task in progress
* Close unnecessary tabs and applications
* Reread every word of the spec
* Only have the relevant terminals and IDEs open
* Close communication apps and email
Get started!