27 Jul 2026•2 min read
Premature automation produces brittle systems for problems that turned out to be temporary. There is a defensible rule for when to build the tool.
24 July 2026•3 min read
Engineers have a reliable failure mode: encountering a manual task once and immediately building infrastructure for it. The task takes twenty minutes; the automation takes six hours, needs maintenance, and handles the one variation that existed at the time. Six weeks later the process changes and the tool becomes a source of confusion rather than leverage.
Do it manually the first time. On the second occurrence, write down the steps. On the third, automate the steps you wrote down. This works because by the third time you know which parts are stable and which vary, and the written procedure is most of the specification.
The exceptions are worth naming: automate immediately when the manual version is dangerous, when it must run at a time nobody is awake, or when correctness depends on doing exactly the same thing every time. Deploys and backups are automated on day one for reasons that have nothing to do with frequency.
A written procedure is undervalued because it is not impressive. But it removes the memory dependency, it lets someone else do the task, it survives a tool change, and it is the artefact you automate from. Many processes never need to progress past this stage, and that is a good outcome rather than a half-finished one.
Against that, the saving is minutes multiplied by frequency. Run the arithmetic honestly and a large share of proposed automation is a hobby with a business justification attached.
The best automation removes a decision, not a keystroke. Anything that still requires judgement halfway through has not really been automated.
Prioritise by risk rather than by frequency: things that are easy to get wrong, things where a mistake is expensive, things done under time pressure. A checklist beats a script for anything requiring judgement, and a script beats a person for anything requiring precision. Choose by the nature of the task, not by how much you enjoy building tools.
@umarrafique923
Author and writer at CandyWrite. Sharing knowledge, tutorials, and reflections on technology, design, and ideas.
Join 12,000+ readers getting our Saturday morning editorial dispatch with our top essays and reading recommendations.
27 Jul 2026•2 min read
29 Jul 2026•3 min read
31 Jul 2026•3 min read
30 Jul 2026•2 min read
Discussion (0)
Join the conversation. Sign in to leave a response or reply to comments.