Recently I wrote about a core ingredient to manageable code: [Relentless Tiny Habits].
Having brilliant code design ideas doesn't necessarily help you manage your codebase better. But building in relentless, tiny habits is likely to bring out some brilliant designs.
I think we can generalize this one essential technique a step further. Habits are indeed very powerful, and greater than the sum of their parts. But a habit is just a special case of an automation.
Instead of thinking of myself as a programmer, I like to frame my job as an automator. Programming is a type of automation. I think you can argue that a habit is a kind of automation as well. It's just that we're automating by training the wiring in our brain instead of automating through code or scripts. Thinking of our role as an automator rather than a programmer can deeply change the way you approach your work.
It's a subtle distinction. I think the power comes from having clarity on what tasks to prioritize, and how to approach your work. Is manually running a set of deployment steps a good use of time for a Programmer? Perhaps. But it's pretty clear that there is some important work to prioritize improving that manual process when you see yourself as an "Automator."
Embrace that role, and use that framing of the role as a cue to step back and make a small investment to automate a repetitive task.
Automation opportunities can take many forms.
There are some broad patterns to look out for.
Stepping back a level, it's important to build the habit of recognizing these signs and taking a moment to identify and address them. There are many ways to do this, like retrospectives or keeping a running list of things that are slowing you down.
These examples may seem obvious because we're used to them. But those tools weren't necessarily obvious before somebody saw that automation opportunity and took action. Could you find similar opportunities in your own codebase? And what low-hanging fruit could you automate right now? Any time you can automate quality and correctness instead of verifying it manually, it's a huge win.
Fully baked automation tools are great. But code is a lot easier to iterate on than hardware. So the best automation you can invest in is automating your habit of making small improvements as you see them!
If you notice repeatedly doing an action in your editor, you could take a moment to look up the keyboard shortcut. Or move a set of manual commands into a repeatable script. You can even think of Making Impossible States Impossible as a type of automation, providing guardrails and ensuring that future changes don't run into the same issues. In Toyota culture, this concept of automating quality is called poka yoke, or foolproofing.
Importantly, these small habits and automations are greater than the sum of their parts. If you learn a keyboard shortcut for the rename function refactoring, you're not only saving the time you would have spent renaming manually or accessing the refactoring with the mouse. You are reducing the barrier to that action, which leads to better names in your codebase over time.
Toyota is famous for the saying that they're not a car manufacturing company. They're a car manufacturing improvement company. Their product is not cars, it's their automated, continually improving process for manufacturing cars. Quality cars are the by-product.
In the same way, you can apply Systems Thinking to your code. You improve the results you're getting by improving the process that generates those results. That doesn't mean you ignore the results. It's essential to drive improvements based on concrete opportunities and pain points, not theoretical or anticipated ones. But once you have something concrete, step back and look at the system, and automate it.
Sign up to get my latest Elm posts and course notifications in your inbox.
Pure Elm content. Unsubscribe any time.