4 ms·

As an addendum perhaps to the Organize and Design Systems section, I'd propose including mise-en-place as it applies to project maintenance and the development

As an addendum perhaps to the Organize and Design Systems section, I'd propose including mise-en-place as it applies to project maintenance and the development environment. This centers on tooling and documentation, especially the README. I want a README that gets me set up and running as quickly and in as few steps as possible. Recently I needed to test out some stuff one of my teams was working on. It was a somewhat complex Wordpress project. I was able to get set up using our documentation, but a couple key steps were missing making it error-prone and unnecessarily aggravating. Anthony Bourdain explains it as only he can: The universe is in order when your station is set up the way you like it: you know where to find everything with your eyes closed, everything you need during the course of the shift is at the ready at arm’s reach, your defenses are deployed. If you let your mise-en-place run down, get dirty and disorganized, you’ll quickly find yourself spinning in place and calling for backup. I worked with a chef who used to step behind the line to a dirty cook’s station in the middle of a rush to explain why the offending cook was falling behind. He’d press his palm down on the cutting board, which was littered with peppercorns, spattered sauce, bits of parsley, bread crumbs and the usual flotsam and jetsam that accumulates quickly on a station if not constantly wiped away with a moist side towel. “You see this?” he’d inquire, raising his palm so that the cook could see the bits of dirt and scraps sticking to his chef’s palm. “That’s what the inside of your head looks like now.” https://books.google.com/books?id=XAsRYpsX9dEC&lpg=PA65&ots=dOy2B3EFxH&pg=PA65#v=onepage&q&f=false https://books.google.com/books?id=XAsRYpsX9dEC&lpg=PA65&ots=...

afarrell 7y ago
Mise-en-place is so important. Inexperienced engineers sometimes find themselves in teams which don’t appreciate it. Because confrontation can be nausea-inducing, they sometimes don’t endure the discomfort to insist on it. ——— When a customer walks into a restaurant, does he ask about the temperature of the fridge the chicken is stored in? Does he ask if the kitchen is clean and organized? No. Thats the chef’s job to insist on. But the customer does care if his food is late or laden with salmonella. Likewise, its an engineer’s job to care if she has automated tests and well-structured code.
- saidajigumi 7y ago
  I'd argue that missing on mise en place is symptom of a team leadership failure, as well. Allowing excessive tribal knowledge vs. repeatable process (docs, dev tools, tests, well organized code, etc.) is an organizational risk. There's the efficiency loss side, but also the possibility that an incapacitated team member becomes a critical business loss – the team becomes unable to meet goals or worst case, to ship at all. Not empowering new team members to efficiently onboard is just one facet of this. With new hires, there are also the power issues that result, particularly blaming new hires for poor onboarding performance. I "fondly" recall one early job in my career starting with the promoted-from-the-ranks dev lead filling a whiteboard with boxes and acronyms... an overwhelming brain-dump to a newcomer that took hours of time spread over days. By the time I'd sorted out what we really did, months later, I could explain the whole thing to a new hire in fifteen minutes. One easily understood diagram, pointers to the two actually-important directories in our codebase, and some context – and they would be off to the races. Funny enough, I met a number of other people at that gig that thought of their work as "irreducible". One was, to use the recent meme, a "10x engineer" for whom the company maintained a rotating roster[1] of tech writers to follow around everywhere and try in vain to record what the heck they were doing. [1] "rotating" as in "hired, then fled screaming"
  - afarrell 7y ago
    I agree deeply.
robohoe 7y ago
It would also help if folks read READMEs. I write a lot of them for my projects at work. Most are detailed but also have a quick setup section in the beginning. Unfortunately people still don’t read them and if they do they miss steps specifically spelled out within markdown formatted code blocks.
0x74696d 7y ago
Totally agreed. I wrote up my thoughts on this recently: https://blog.0x74696d.com/posts/mise-en-place/ https://blog.0x74696d.com/posts/mise-en-place/

afarrell 7y ago

Mise-en-place is so important. Inexperienced engineers sometimes find themselves in teams which don’t appreciate it. Because confrontation can be nausea-inducing, they sometimes don’t endure the discomfort to insist on it. ——— When a customer walks into a restaurant, does he ask about the temperature of the fridge the chicken is stored in? Does he ask if the kitchen is clean and organized? No. Thats the chef’s job to insist on. But the customer does care if his food is late or laden with salmonella. Likewise, its an engineer’s job to care if she has automated tests and well-structured code.

saidajigumi 7y ago
I'd argue that missing on mise en place is symptom of a team leadership failure, as well. Allowing excessive tribal knowledge vs. repeatable process (docs, dev tools, tests, well organized code, etc.) is an organizational risk. There's the efficiency loss side, but also the possibility that an incapacitated team member becomes a critical business loss – the team becomes unable to meet goals or worst case, to ship at all. Not empowering new team members to efficiently onboard is just one facet of this. With new hires, there are also the power issues that result, particularly blaming new hires for poor onboarding performance. I "fondly" recall one early job in my career starting with the promoted-from-the-ranks dev lead filling a whiteboard with boxes and acronyms... an overwhelming brain-dump to a newcomer that took hours of time spread over days. By the time I'd sorted out what we really did, months later, I could explain the whole thing to a new hire in fifteen minutes. One easily understood diagram, pointers to the two actually-important directories in our codebase, and some context – and they would be off to the races. Funny enough, I met a number of other people at that gig that thought of their work as "irreducible". One was, to use the recent meme, a "10x engineer" for whom the company maintained a rotating roster[1] of tech writers to follow around everywhere and try in vain to record what the heck they were doing. [1] "rotating" as in "hired, then fled screaming"
- afarrell 7y ago
  I agree deeply.

robohoe 7y ago

It would also help if folks read READMEs. I write a lot of them for my projects at work. Most are detailed but also have a quick setup section in the beginning. Unfortunately people still don’t read them and if they do they miss steps specifically spelled out within markdown formatted code blocks.

0x74696d 7y ago

Totally agreed. I wrote up my thoughts on this recently: https://blog.0x74696d.com/posts/mise-en-place/ https://blog.0x74696d.com/posts/mise-en-place/