Principle: Automate the second time

Teams either automate too early (wasting time on one-off tasks) or too late (suffering through manual repetition).

The rule of three for automation:

First time: Do it manually. Learn the process.
Second time: Do it manually but take notes. Notice patterns.
Third time: Automate it.

Why not automate the first time?

• Requirements aren't clear yet
• You don't know the edge cases
• The task might never recur
• Manual understanding informs better automation

What to automate immediately (exceptions):

• Anything that's a deployment safety check
• Anything that's a human error risk (production operations)
• Anything that blocks other people while waiting for you

What to never automate:

• Truly one-off tasks (migration scripts are reusable, though)
• Tasks where human judgment is the point (code review decisions)
• Things that change every time (ad hoc data analysis)

Good automation targets:

• CI/CD pipeline (build, test, deploy)
• Environment setup (dev containers, dotfiles)
• Repetitive data transformations
• Incident response runbooks (partial automation)
• Dependency updates (Dependabot/Renovate)

The meta-principle: Automate the process of automation. Good templates, scripts, and conventions make creating new automation fast.

Premature automation is a form of premature optimization. But unlike code optimization, the cost of manual work is linear and visible, making it easier to justify.

Deciding what to automate in development workflows