The Case for Doing Things Manually Before You Automate
The Case for Doing Things Manually Before You Automate
There is a temptation in software development to automate everything immediately. Write a script for it. Build a pipeline. Set up a cron job. Automation is one of our superpowers as developers, so we reach for it instinctively.
But there is a problem that nobody talks about: automating something you do not fully understand is one of the most reliable ways to create bugs that are nearly impossible to find.
The Premature Automation Trap
Here is a scenario that plays out constantly in teams everywhere.
A developer notices a repetitive task. Maybe it is deploying to staging, or processing uploaded files, or syncing data between two systems. Instead of doing it a few more times by hand to really understand the edge cases, they immediately write a script.
The script works great for the common case. Then, three weeks later, it silently fails on an edge case nobody anticipated. Data gets corrupted. Deployments break at 2 AM. A customer's file gets processed incorrectly and nobody notices for days.
The automation did not just fail to help. It made things worse. Because when you do something manually, you notice when something looks wrong. Automation does not notice. It just keeps running.
Why Manual First Works
You Discover the Edge Cases
When you process files by hand, you notice that some of them have weird encoding. You notice that certain filenames have spaces in them. You notice that the timestamp format is inconsistent across sources.
These are the exact things that will break your automation later. But you only discover them by actually handling the data yourself.
You Understand the Real Requirements
The task you think you are automating and the task you are actually automating are often different. Doing it manually a dozen times shows you the real workflow, including all the little judgment calls and exceptions that were never documented.
You Build Better Automation
When you finally do automate, your script handles the edge cases because you already know about them. Your error handling covers real scenarios, not hypothetical ones. Your logging captures the things that actually go wrong.
The difference between automation built by someone who has done the task 50 times by hand and automation built by someone who read a spec document is enormous.
The Right Time to Automate
Automation makes sense when three conditions are met:
- 1You fully understand the task, including its edge cases and failure modes
- 2The task is truly repetitive and will be done many more times in the future
- 3The cost of manual errors exceeds the cost of building and maintaining the automation
Notice that "it is boring" is not on the list. Boring is not a good enough reason to automate. Boring tasks that are done rarely are fine to do by hand.
And notice that the third point mentions maintenance. Every automation script is code that needs to be maintained. When the underlying system changes, the script needs to change too. If the task only happens once a month, the maintenance burden might outweigh the time saved.
Real-World Examples
Deployments
Before setting up a CI/CD pipeline, do a few manual deployments. SSH into the server. Run the build commands yourself. Copy the files. Restart the services. Watch the logs.
You will quickly learn which steps are fragile, what order they need to happen in, and what can go wrong. Your pipeline will be much more robust because of it.
Data Processing
Before writing a data pipeline, manually process a sample of the data. Open it in a spreadsheet. Look at the actual values. Notice the inconsistencies. Find the rows that do not fit the expected format.
Then build your automation to handle all of it, not just the happy path.
Testing
Before writing automated tests, test the feature manually a few times. Click through the UI. Try weird inputs. Break it intentionally. You will write much better test cases because you have firsthand experience with how the feature actually behaves.
File Conversions
Before building a batch file converter, convert a few files by hand using a browser-based tool. Notice how different input formats produce different results. Notice which settings matter and which ones do not. Then build your batch process with that knowledge.
The 3x Rule
A practical guideline: do a task manually at least 3 times before you consider automating it.
- •First time: You are just learning how it works
- •Second time: You start noticing patterns and edge cases
- •Third time: You have a clear picture of what automation would need to handle
If after 3 times it still feels worth automating, go for it. You will build something much more reliable than if you had jumped straight to code.
Some people extend this to a "Rule of Three" for code as well: do not abstract something into a function or utility until you have written it three times. The first two times teach you what the right abstraction actually is.
When to Skip Manual and Automate Immediately
This is not a universal rule. There are legitimate cases where you should automate right away:
- •Safety-critical tasks where manual execution risks human error (like database migrations with rollback steps)
- •Tasks with well-documented, stable requirements that are not going to surprise you
- •Tasks where the automation already exists and you just need to configure it (no need to reinvent CI/CD from scratch)
- •Compliance and audit tasks where you need a reproducible, logged process
The key difference is that in these cases, the requirements are already well-understood. Someone, somewhere, has already done the manual work of figuring out the edge cases.
The Takeaway
Automation is one of the most powerful skills a developer has. But like any power tool, it can cause a lot of damage if used carelessly.
The next time you catch yourself thinking "I should write a script for this," pause and ask: "Have I done this enough times by hand to actually understand what I am automating?"
If the answer is no, do it manually a few more times. The automation you build afterward will be faster, more reliable, and easier to maintain. And you will have saved yourself from debugging a mysterious failure at the worst possible time.