What I Automated This Month

I like big projects, but a surprising amount of engineering improvement comes from small automations that quietly remove repeated friction.

This month I found myself thinking less about “what should I build next?” and more about “what keeps stealing time that should not?”

Automation as a forcing function

The useful automations are rarely glamorous. They are often the duct tape that holds a developer's workflow together. This month, I focused on three specific areas where manual effort was becoming a drag on my shipping speed.

1. Scaffolding for MDX content

I realized I was spending too much time copying-and-pasting frontmatter for new blog posts and notes. I wrote a small Go CLI tool that takes a title and a category, then generates a slug-prefixed MDX file with the correct metadata blocks. It saves maybe 30 seconds per post, but it removes the "blank page" friction entirely.

2. Deployment Sanity Checks

Before every push to production, there are a few things I used to check manually: environment variable consistency, image tag updates in K8s manifests, and linting status. I moved these into a pre-commit shell script. Now, if the local state doesn't match the expected production baseline, the commit fails. It’s a simple gate, but it prevents the "oops, I forgot the ENV" incident.

3. Log Aggregation Refinement

I spent some time automating how I categorize logs in Loki. Instead of manually filtering by labels every time, I set up a few recorded rules that aggregate common error patterns into a dedicated "Noise" dashboard. This lets me focus on actual anomalies rather than the background radiation of a healthy system.

The "Three Times" Rule

Whenever I do something three times and it still feels annoying, it probably deserves one of three things:

• A checklist: If the process is complex but doesn't require a script.
• A script: If the process is repeatable and can be safely automated.
• A reusable template: If the friction is in the structure rather than the logic.

That simple rule has improved my workflow more than most productivity advice I've read.

Why this matters

As I build a more public portfolio around DevOps and reliability, I don't want every new page or project to feel like a separate, heavy lift. Automation is not just about scale; it's about respect for your own attention. If a workflow keeps draining focus without adding value, it's a bug that needs fixing.

Final thought

The goal of automation isn't to stop working. It's to make sure you're spending your limited engineering energy on things that actually matter—like architecture, reliability, and solving real problems—rather than formatting markdown or double-checking environment variables.