Stop Doing Repetitive Work Manually: Start Automating

It is 11pm. You have a list of 300 IP addresses and someone needs to know which ones are still reachable before the change window closes. So you open the terminal and start typing ping, one address at a time. By address number forty your eyes have glazed over. By address number two hundred you have already made a typo and pinged the wrong host twice.

You are not bad at your job. You are doing a machine’s job by hand.

Almost every IT professional has a task like this — quiet, boring, repetitive kerja that eats an hour here and two hours there. It rarely shows up in a report, so nobody counts it. But add it up across a month and it is real time, real overtime, and real mistakes.

This article is about learning to see that work, and taking the first honest step toward automating it. You do not need to be a programmer to follow along. You just need to be someone who is tired of doing the same thing over and over.

The work you are probably doing by hand right now

Look at your week. If any of these feel familiar, you are looking at automatable work:

• Repeated Excel or CSV processing — same cleanup, same columns, every week
• Renaming or organising large batches of files
• Copying a config and changing three values for the next device
• Checking hundreds of IP addresses or devices for reachability
• Generating the same report again and again
• Extracting specific lines from logs
• Comparing two files or two configs to find what changed
• Repeating the same steps across many systems
• Routine data cleanup — trimming, formatting, de-duplicating
• Manually preparing technical documentation

Notice what these have in common. They are mechanical. The steps do not really change from one run to the next. Your brain is not solving a new problem each time — it is replaying the same recording. That is exactly the kind of work a computer is good at and humans are bad at, because we get bored, and bored people make mistakes.

Automation is not “using AI”

Before we go further, let us kill one misunderstanding.

Automation does not mean building a complicated AI system. It does not require a data science team or a cloud budget. Most useful automation in real IT work is small and unglamorous:

• A short Python script that reads a CSV and spits out a clean one
• An Excel formula or macro that does the monthly report for you
• A small Windows EXE that pings a whole device list and flags what is down
• A quick API call that pulls data instead of you copy-pasting it from a portal
• A simple workflow that chains two of these together

The goal is not to “use technology” for its own sake. The goal is a chain:

Reduce repetitive work → reduce errors → save time → simplify the workflow.

If a piece of automation does not do at least one of those, it is not worth building. Keep that sentence in mind — it is the whole point.

How to think about automation before writing any code

Here is the part most tutorials skip. They jump straight to code. But the thinking comes first, and the thinking is where beginners can absolutely keep up. Use this simple framework.

1. Identify repetitive work. Watch yourself for a week. The task that makes you sigh, the one you dread, the one you do “quickly” five times a day — that is your candidate.

2. Understand the current manual workflow. Write down every step you actually do, in order. Do not tidy it up. If you open a portal, export a file, paste it into Excel, delete two columns, and email it — write all five steps. You cannot automate a process you cannot describe.

3. Identify inputs and outputs. What goes in? (A CSV, a list of IPs, a folder of configs, an API response.) What comes out? (A clean report, a list of failed devices, a diff, a formatted document.) Automation is really just a reliable path from input to output.

4. Identify the repetitive rules or decisions. What do you decide each time, and by what rule? “If the ping fails, mark it red.” “If column C is empty, drop the row.” These little rules are the logic your script will follow. If a decision truly needs human judgement every time, leave that part to the human.

5. Estimate the time and errors involved. Be honest. Ten minutes a day is about 40 hours a year — a full working week. And how often does a manual run go wrong? Every typo, every skipped row, every wrong file is a real cost.

6. Decide whether automation is worthwhile. Not everything should be automated. If you do it once a year in five minutes, leave it alone. Automate the tasks that are frequent, mechanical, and error-prone. That intersection is where automation pays for itself fast.

7. Start with a small solution. Do not try to build the perfect system. Automate one step. Ping the list. Clean the one column. Compare the two files. A small win you can trust beats a big system you never finish.

8. Improve it over time. Once the small piece works and you trust it, extend it. Add the second step. Handle the edge case. Automation grows; it does not have to arrive fully built.

A realistic example, start to finish

Say you are a NOC engineer and every morning you check whether 200 customer routers are reachable, then note the ones that are down.

• Manual workflow: open terminal, ping each IP, write down the failures in a notebook, retype them into an email. Twenty to thirty minutes if nothing goes wrong.
• Input: a list of 200 IPs in a text file or CSV.
• Output: a short list of which IPs failed.
• Rule: if a host does not reply, it is “down.”
• Time and errors: ~30 minutes a day, and it is easy to skip a line or mistype an address at 6am.

This is a textbook automation candidate: frequent, mechanical, error-prone. A small script — or a ready-made tool — reads the list, pings everything in seconds, and hands you only the failures. The 30-minute chore becomes a 10-second check, and it does not skip lines when it is tired, because it never gets tired.

The same shape applies far beyond networking. A sysadmin renaming 500 log files by a pattern. An analyst cleaning the same messy export every Monday. A support engineer comparing yesterday’s config against today’s to find what someone changed. Different jobs, identical structure: repeated input → same rules → predictable output.

The one skill worth building

If you take one thing from this article, make it this habit: start noticing the mechanical parts of your day and asking, “could a computer do this exact thing?”

That question, asked honestly, is more valuable than any single script. It is the difference between an engineer who works hard and one who works smart. You do not have to automate everything tomorrow. You just have to find one task — the most annoying, most repetitive one — and decide it is your first project.

Where EZKerja fits

EZKerja exists for exactly this journey. The whole brand is three words: Learn. Automate. Simplify. — practical technology learning, tools, and courses for people who do real technical work and want to stop doing the boring parts by hand.

• If your repetitive work is checking device reachability or subnet maths, that is the kind of task the Network Engineer Toolkit is built to remove — bulk ping a whole list and get back only what is down, and do subnet/VLSM calculation without the manual arithmetic.
• If your work involves comparing configs to find what changed, that is what the Config Diff Reporter is for — point it at two config files and it shows you the real differences instead of you reading line by line.
• And if you want to go past ready-made tools and write your own automation, the Network Automation course takes you from doing everything by hand to building a working config-backup script against your own devices — taught in Malay and English, with your actual script reviewed and fixed.

None of these replace the thinking above. They are what the thinking leads to once you have spotted the right task.

CTA

Pick one repetitive task from your week — the one you dread most — and run it through the eight steps above. That is your first automation project. When you are ready to stop doing it by hand, explore the EZKerja Network Engineer Toolkit or the Network Automation course — both are linked below.