A Model of Small Decisions

# Model of Small Decisions ## Re: Try to avoid multitasking As a fullstack developer I find this particularly apt. I'm most productive when I deliberately focus on one part of the stack at a time (think days, not hours) and I rely heavily on the notes that I take to provide context.

## Re: Remembering effective rules When I'm documenting, often I'm in the mindset of, "I solved this problem today, and writing it down ensures that I won't have to re-solve it next month"

## Re: Minimizing decisions My most productive days revolve around making decisions up-front, ie planning out the steps of a project in a Kanban or bullet journal at a granularity of 30 min chunks (~15 min expected time, 15 min slack)

# Possibly Related Work ## Readme Driven Development https://tom.preston-werner.com/2010/08/23/readme-driven-deve... The idea is to write your readme before you start coding. Just enough upfront planning to imagine what the system will be, discuss with team, and make changes, while delaying making all the small decisions that are needed to actually bring it to life.

I think that RDD is an admission that small decisions exist, so we should try to make the best big decisions that we can up-front while the cost of change is lowest. Each of the small decisions that you make in coding adds friction to change.

## Basecamp Hill metaphor https://basecamp.com/features/hill-charts "The idea: work is like a hill Every piece of work has two phases. First there’s an uphill phase where you figure out your approach. You have a basic idea about the task, but you haven’t figured out what the solution is going to look like or how to solve all the unknowns.

Eventually you reach a point where there aren’t any more unsolved problems. That’s like standing at the top of the hill. You can see clearly all the way down the other side. Then the downhill phase is just about execution."

This too I feel is an admission that small decisions exist. It's an understanding that even when you have a plan, projects go through a phase in the beginning where there's a concentration of decisions that need to be made, and each of those decisions introduce some measure of uncertainty.

Small decision is better compare to complex decision, which most likely is not small.

software is made of decisions - someone said.

so is life, but it's waaaaay less obvious, too many of the decisions are materialized into something and do not appear as such.

that table can grow big. Enormous. And then one day choosing between alternatives for X becomes a problem on itself. But that still allows flexibility, and one can learn to control it, and so is still better than the other possibility, one-and-only hardcoded solution for everything. No new stuff, only rigid traditions.

so.. keep changing it. growing it. like a garden. of your thoughts