Mise en Place Writing
swyx.io
swyx.io
In brief though, let's say you're implementing network filtering (inspired by today's LittleSnitch post).
Before writing any code, I would:
- Figure out what actual business case there is behind it and what the management/customer/etc is actually looking for. Maybe feature XYZ isn't the right long/short-term solution for what they want. People give Steve Jobs a lot of flack for "you're holding it wrong", but he was right in the sense that the customer doesn't always know what they want/need, let alone know what's even possible.
- Once the feature is what is required, figure out what's the right fit for the feature within the current architecture with short/medium/long-term goals in view. Maybe it's actually better to hack something in quickly and commit to revisit in 1 week than spend a month doing it right and lose users.
- Then figure out if the APIs actually exist. Some APIs you need simply don't exist. For example, in order to filter network traffic on MacOS, you needed to write a kernel extension until macOS Catalina. If your architecture/business doesn't have room for kernel extensions, then those APIs are out of reach. (Maybe Apple didn't bless your request to code sign kexts. Maybe you have no-one on your team with kernel experience. Maybe your customers are non-admin users on their Macs that can't load kexts.) During this phase, I might write some quick & dirty PoC code later in the process to exercise all the necessary APIs and make sure those actually do what they promise to do within my constraints.
Once you have the business requirements, stakeholders aligned, and PoC that exercises all the APIs which demonstrate your feature's needs, writing the actual code is a breeze. Especially once you get pretty good at this, transforming the PoC code into one that stands the test of time in your product gets easier and easier.
You may ask "wait, writing the PoC code is exactly what you claimed you didn't do!". You've got a point, except in this case, whenever I write PoC code, I write it as a standalone "proving grounds" program. I don't start writing code within the product's architecture. I would estimate in my PoC code, there's less than 3% that is outside of exercising the necessary APIs.
I said it's irrational, right? :)
[1] https://developer.mozilla.org/en-US/docs/Web/CSS/scrollbar-c...
Ex: you can buy carrots precut from the grocery store in "matchstick" form. You can buy pre-minced garlic. You can buy pre-soaked + cooked canned beans. There's no reason to work overly hard preparing meals.
Not everything is available pre-made in the grocery store. But the preparations you do can be batched up into larger sections. Cut the entire onion, or two, or three. Then tomorrow, you have pre-cut onions for other meals. Don't cook 1 cup of rice for today, cook 3 or 4 cups, so that you have rice for fried rice tomorrow.
------------
I like the idea of prep-work being applied to writing. Batching additional work together can make you more efficient in cooking, so it makes sense that batching research together (for many different articles) would make you a more efficient writer, when it comes to writing many (say, 50 articles) at once.
The idea of pre-cut veggies and pre-minced garlic isn't to make things as tasty as possible. No... the idea is to make the joy of cooking far easier.
Give me a pint of leftover rice, a jar of pre-minced garlic, a can of corn, 2 eggs, and an onion and I'll cook you some fried rice in less than 10 minutes. The longest part of the job is waiting the 5 minutes for my cast-iron skillet to heat up.
1. Heat cast iron skillet (~3 to 5 minutes)
2. Simultaneously, cut the onion. One half the onion is for this meal, save the other half for tomorrow.
3. Pour oil into the pan, wait for it to smoke lightly (shouldn't be long if its hot enough).
4. Mix rice, pre-minced garlic, corn, eggs, and cut onion into the skillet.
5. Mix around for a few minutes.
6. Eat. Add salt and pepper to taste.
---------
Mincing garlic so that its fresh will taste better. But that's not "daily eating" IMO.
Cooking quickly and cheaply is a major skill. The corn is pre-kerneled, the garlic is pre-minced. The only thing I have to do is cut the onion, heat up the pan and fry everything.
I eat fast food because it is easy. Making cooking easier than fast food is important, because then I self-cook instead of eat fast food. As long as it tastes better than a McDonald's Big Mac... and as long as it takes less effort than driving to McDonalds, I'll be cooking at home.
Depending on the recipe, freeze-dried garlic is even better because you can control how quickly it browns by adjusting the amount of water when rehydrating it.
[1] At least, it was cheaper last time I checked.
Soaking and cooking raw, dry beans is time consuming and there are actually food safety concerns (dry kidney beans are toxic). So, getting canned beans will save you a significant amount of prep. I prefer the taste of beans that I’ve made myself but it’s rarely worth the high effort.
On the other hand, it doesn’t take much time to mince garlic, and it tastes a lot better than the stuff in jars.
Tubes of cookie dough and bags of “pie crust” mix are nearly as good as preparing everything at home, so there’s little benefit to making them yourself unless you’re going to change the recipe. Jars of spice mixes are great if you don’t want to deal with a full spice rack.
On the other hand, if you want juice, fresh squeezed is far better than the jugs or cartons of juice at the store, or the concentrate. The flavors in a fruit don’t last long when exposed to air, so the juice companies generally add scents to the juice—basically, perfume—and they have a clever trick to keep it off the ingredients list: they make it from the fruit.
The idea is to do the work that has the highest impact on the food quality, and then outsource everything else to industry.
If I'm using canned and pre-cut veggies, then minced garlic means I don't even have to take out the cutting board.
I agree, fresh-minced garlic tastes way better. But pre-minced garlic is "good enough" in most cases.
> Sous-chefs are in charge of making sure all kitchen equipment is in working order. [...] Under the oversight of the sous-chef, downtime should be used for prepping, cleaning and other kitchen duties.
In the body of a document titled "Mise en Place Writing," I do believe the author meant exactly that chefs[1] are the ones making sure all forms of preparation are completed, even if it means working the prep station.
In fact, I'd go so far as to say I'm certain this particular author checked a resource like a list of culinary terms or restaurant terminology[2] during a "pre-writing" phase like "Research" before using those words at all.
[0]: https://en.wikipedia.org/wiki/Sous-chef
[1]: "A chef is a trained professional cook and tradesman who is proficient in all aspects of food preparation" emphasis added by me, https://en.wikipedia.org/wiki/Chef
[2] https://en.wikipedia.org/wiki/List_of_restaurant_terminology
Just because it has the word "chef" in it, does not make the sous-chef "chef". Sure, in layman's terms they are "a kind of chef" but in professional terms, they are not. There's only one chef, they're the CEO of kitchen, they rarely prep.
Additionally it's the first time I think I've seen a styled scrollbar that fit into a site (ie: wasn't a demo of styling a scrollbar) since Angelfire/Geocities/etc -- I know it's been a long time because I actually checked the source and realized I didn't even remember the CSS names, just doing it in IE!