Mise-en-place for knowledge workers(fortelabs.co)
fortelabs.co
Mise-en-place for knowledge workers
https://fortelabs.co/blog/mise-en-place-for-knowledge-workers/
84 comments
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.
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.
The biggest benefit for me is that it lets me put everything away without the anxiety of losing anything.
ooh histre looks pretty neat!
Thank you! Please let me know if you have any questions. I can be reached at [email protected]
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)
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)
Do you save the tab history?
IE its back and forward links?
I find it really frustrating that most solutions don't do this...
I find it really frustrating that most solutions don't do this...
That's a great idea. I don't, but I will. Thanks.
No problem, definitely let me know when you add it :)...
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.
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.
[1] https://addons.mozilla.org/en-US/firefox/addon/simple-tab-gr...
[1] https://addons.mozilla.org/en-US/firefox/addon/simple-tab-gr...
Dude. You should use Amna. It takes that exact workflow you mentioned and packages it nicely. Imagine a task manager that also manages your browser
I actually read the book mentioned in the blog post. Here’s my “Mise-en-place” workflow:
https://www.getamna.com/blog/calendar-task-organization/
I actually read the book mentioned in the blog post. Here’s my “Mise-en-place” workflow:
https://www.getamna.com/blog/calendar-task-organization/
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 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.
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.
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.
Same here. Tried a few times previously, but this time I took the time to set up proper keyboard shortcuts which made all the difference.
For windows, this project is a great way to get keyboard shortcuts for desktop switching: https://github.com/yalibian/i3-windows
For windows, this project is a great way to get keyboard shortcuts for desktop switching: https://github.com/yalibian/i3-windows
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.
It's a very pleasant way to work.
I also like to go through and clear house when I have several tabs open.
It's a very pleasant way to work.
I keep three windows - two on my main 4K monitor. A third on my glitchy old one. Each window must have one thing.
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.
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.
> 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.
Well, multitasking was all the rage not so long ago. A lot of people got bombarded with blog posts and articles about it.
I feel the same. It’s just way too overwhelming.
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
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 work similar to this.
I think you have inspired me to go full on with it.
I think you have inspired me to go full on with it.
> Because of this brutal reality (In cooking, a dish that is 99% finished has zero value), chefs must adopt a “finishing mindset.”
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
https://books.google.com/books?id=l8tUCwAAQBAJ
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
https://books.google.com/books?id=l8tUCwAAQBAJ
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.
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.
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.
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.
> Either redefine the project
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.
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.
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.
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.
Old advice I got from a Project Director : "90% means you are almost half way done"
Didn't know it takes Project Director to give that advice.
I always thought it is rather common sense, borne from experience: https://en.wikipedia.org/wiki/Ninety%E2%80%93ninety_rule
I always thought it is rather common sense, borne from experience: https://en.wikipedia.org/wiki/Ninety%E2%80%93ninety_rule
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.
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.
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!
With software you are never done so you have to decide to be done!
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 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.
This analogy kind of rubs me the wrong way.
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. 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.
(Which I also completely agree with).
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).
At the extreme, someone behaving like this doesn't seem like a great person to work with.
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.
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.
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.
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.
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.
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 do like the concept of having Mise for us "knowledge workers" too.
>I'm not sure my body could take that kind of work now
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.
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 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.
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 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.
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.
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 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.
voidtools' Everything (https://www.voidtools.com/) is one of the first things I install on a new Windows system. Instantaneous filename search.
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 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.
> standardized tasks such as welding a seam
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.
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.
If it looks correct, how do the CWIs identify unacceptable welds?
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).
https://www.cruxweld.com/blog/quality-weld-inspection/
TLDR: x-rays, ultrasonic testing, and liquid penetration tests
TLDR: x-rays, ultrasonic testing, and liquid penetration tests
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.
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
Interesting comparison.
Heads up for the author that this skips #6, and goes from 5 to 7.
Heads up for the author that this skips #6, and goes from 5 to 7.
[deleted]
The author's PARA method for organizing / structuring digital info is helping me a lot. It gives me a solid bedrock. https://fortelabs.co/blog/para/
> [...] and this is reflected in the strictly defined roles he created for the kitchen:
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).
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).
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.
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.
So little of css is work is in color picking that I don’t think color blindness matters.
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.
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.
Information marketing about information products for knowledge work. My head hurts.
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.
https://www.workclean.com/
https://www.workclean.com/
The intern system at large companies is supposed to, and often does implement the same apprentice function that the trades have.
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.
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.
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.
I like to:
* 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!
* 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!
Anyone here building a second brain?
He died at age 88 not 99.
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.