[HN Gopher] Mise-en-place for knowledge workers
       ___________________________________________________________________
        
       Mise-en-place for knowledge workers
        
       Author : ingve
       Score  : 184 points
       Date   : 2021-07-02 07:22 UTC (15 hours ago)
        
 (HTM) web link (fortelabs.co)
 (TXT) w3m dump (fortelabs.co)
        
       | gumby wrote:
       | The intern system at large companies is supposed to, and often
       | does implement the same apprentice function that the trades have.
        
       | jamestimmins wrote:
       | Interesting comparison.
       | 
       | Heads up for the author that this skips #6, and goes from 5 to 7.
        
       | galaxyLogic wrote:
       | Smalltalk-80 had a fantastic work-management tool. I haven't
       | checked lately but I think Squeak and Pharo Smalltalk
       | environments still have the same.
       | 
       | 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 and debuggers etc. You can
       | open nested projects as deep as you wish. You can exit a project
       | but it still remains, 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 open in it.
       | 
       | 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 Smalltalk desktop. Once that sub-task is
       | done you can exit that project and close its window.
       | 
       | 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 on "project windows" on it and share it without co-workers.
       | These sub-projects could describe the subtasks and allow you to
       | record you progress in them, say for cooking a specific meal.
       | 
       | 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.
        
       | [deleted]
        
       | Zababa wrote:
       | 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).
        
       | LunaSea wrote:
       | He died at age 88 not 99.
        
       | sbuk wrote:
       | 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/
        
       | skinkestek wrote:
       | > [...] 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).
        
         | kortilla wrote:
         | So little of css is work is in color picking that I don't think
         | color blindness matters.
        
         | svachalek wrote:
         | 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.
        
       | itomato wrote:
       | > 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
        
         | pc86 wrote:
         | 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.
        
           | mdoms wrote:
           | 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.
        
           | lmilcin wrote:
           | > 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.
        
             | kortilla wrote:
             | > 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.
        
               | dcastonguay wrote:
               | 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.
        
             | svachalek wrote:
             | 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.
        
             | jimmySixDOF wrote:
             | Old advice I got from a Project Director : "90% means you
             | are almost half way done"
        
       | mberning wrote:
       | 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.
        
         | clipradiowallet wrote:
         | > 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.
        
           | AlexCoventry wrote:
           | If it looks correct, how do the CWIs identify unacceptable
           | welds?
        
             | krallja wrote:
             | https://www.cruxweld.com/blog/quality-weld-inspection/
             | 
             | TLDR: x-rays, ultrasonic testing, and liquid penetration
             | tests
        
             | aksss wrote:
             | 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).
        
       | blakesterz wrote:
       | 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.
        
         | rcoveson wrote:
         | > loud and dangerous and hot and chaotic
         | 
         | 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.
        
           | itomato wrote:
           | Grills & hoods and hot rows feel eerily similar, down to the
           | din.
        
         | slg wrote:
         | >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.
        
           | pc86 wrote:
           | 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.
        
       | mamborambo wrote:
       | 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
        
       | Zababa wrote:
       | > 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.
        
         | nyanpasu64 wrote:
         | 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.
        
           | Zababa wrote:
           | > 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.
        
         | mywacaday wrote:
         | 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.
        
           | nlawalker wrote:
           | voidtools' Everything (https://www.voidtools.com/) is one of
           | the first things I install on a new Windows system.
           | Instantaneous filename search.
        
       | whytaka wrote:
       | 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.
        
         | codyb wrote:
         | 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.
        
         | leokennis wrote:
         | 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"
        
         | SN76477 wrote:
         | I work similar to this.
         | 
         | I think you have inspired me to go full on with it.
        
         | georgeam wrote:
         | 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.
        
           | reddit_clone wrote:
           | 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.
        
         | johnchristopher wrote:
         | > 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.
        
         | draw_down wrote:
         | Same here. If I'm not using it it's gone. If I need it for
         | later I'll save it somehow. My computer should have very little
         | local state. Losing a window with dozens of tabs shouldn't be
         | some devastating loss. If it's important save it.
        
       | t0mbstone wrote:
       | 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.
        
         | joshuaheard wrote:
         | 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.
        
       | mcbishop wrote:
       | 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/
        
       | bob1029 wrote:
       | 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.
        
         | hinkley wrote:
         | 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.
        
           | murphm8 wrote:
           | 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...
        
       ___________________________________________________________________
       (page generated 2021-07-02 23:00 UTC)