I don’t spend enough time working on my own projects. With an actual software job, general human responsibilities, and the occasional desire to pursue a goal beyond the screen of my laptop, I find myself spending — on a good week — a couple hours working on any given project.

When I’m working on something for hours every day, the workflow for building, testing, and deploying my changes become muscle memory. I click buttons and enter commands without thinking. The non-productive time between iterations gets whittled down until it’s mostly a factor of how quickly I can type or how fast a page loads. Let a project sit for a month (or six) and it’s a different story.

Coming back to my own code after a while can be humbling. I’ve usually left myself zero documentation, no notes or TODOs, and, if I’m lucky, a cobbled-together suite of outdated scripts that once managed something and now do nothing. The process of reading my code, finding the right infrastructure to update, deciding which steps are dangerous, and re-inventing the update wheel might take an hour or two. An hour spent decoding the system is a huge hit to my productivity if I’ve only got a couple hours to begin with. After years of repeating this cycle, I’ve finally committed to the only process improvement that can help.

Begin every project by capturing the build and deploy workflow in code.

Of course, I break this rule all the time. I can confidently say a project’s first keystrokes have never been spent typing an update script, and that’s fine. I usually have to spend some time working on a project before deciding that it’s worth pursuing. If it is worth coming back to, whether it’ll ever be finished or not, I give it a fighting chance by creating some basic automation.

At the very least, I’ll capture the commands I need to run a build. I’m not struggling to remember the correct order of operations in bundling and packaging steps. If it’s a web project, I’ll define the steps to push the changes so they happen automatically. If the code gets deployed to Lambdas, I’ll make sure I don’t have to click around the AWS console to find which functions might be associated with this project and might need the update.

I’ve applied my approach to this site. It’s not complicated, just a collection of static pages generated whenever I make a change, but I’m never more than a git push from setting the deployment wheels in motion. Two minutes later, the change is live and I don’t even remember how it got there.