Published: Mar 23, 2021 by

At heart many of us are tinkerers. We like to take things apart and see how they work. We enjoy spending hours customizing our tools, scripts and applications. But all of this adds up. It means that our tool works different from all the others. For somebody else coming behind us it may mean piecing together all the flags and tweaks no matter how well we documented or versioned tweaks in our repo, time will bring a divergence between the system and the repo.

A lot of this has set in for me over the years teaching programming, speaking with family about their devices, and onboarding to new code bases as I change teams.

I want to try out something new over the next few years, and that is finding good defaults. If I feel the need to tweak/change a tool out of the box, I’ll try other options. I have some theories around this.

• Good defaults save us time
• Don’t require extra conversations for team consensus
• Help manage complexity
• Build on expertise
• Teach us to expect good defaults, and to build our software with good defaults
• Good defaults help others join in

Against this list I also believe there is a counter culture around defaults wrapped up in programmer/hacker/software engineer reputation that drives us to distrust or question anything we haven’t pulled apart and customized. This creates an extra challenge.

I know that each domains “good defaults” will be different, but that doesn’t mean they don’t exist. My hypothesis is that they can save us time, help us build what matters, and help those who are join in, or come after. Lets find out.