From Student to Computer Technician: Where My Software Engineering Journey Really Started

Long before I became a software engineer, full-stack developer, or technical lead, I was a Computer Science student trying to understand how computers actually worked outside the classroom.

While completing my degree, I was also working as a computer technician. I studied during the day and worked with real computers, networks, servers, users, and business systems after school and at night.

Looking back, that experience taught me lessons that stayed with me throughout 20+ years in software engineering.

My classroom continued after school

The technology was very different from what developers use today. This was the era of DOS, Windows 3.11, Clipper applications, physical network cabling, and servers sitting somewhere inside the building rather than somewhere in the cloud.

My work wasn't limited to fixing PCs. I laid UTP network cables, installed and maintained computers, helped install company servers, supported users when something wasn't working, and eventually became involved with the systems and data that helped keep the business operating.

University taught me the fundamentals of computing. Work taught me what happens when those computers actually matter to somebody.

Knowing how something works and making it work in the real world are two different skills. You need both.

I was also learning how a business works

Something unexpected happened while I was learning technology: I started learning business operations.

Working around supermarkets and malls allowed me to see how different parts of the business connected. Customers bought products at the cashier. The POS systems recorded those transactions. Departments generated sales information. Data had to be processed. Reports eventually reached management so they could understand how the business was performing.

I began to realize that the computers I was maintaining weren't isolated machines. They were part of a much larger system.

And sometimes I learned that lesson the hard way.

The night I discovered production impact 😴

Our business applications were built using Clipper, and part of our nightly work involved rebuilding indexes. Those indexes needed to be processed properly so the systems would be ready for business the following day.

At first, I wasn't running all the processing efficiently across multiple available computers. Some jobs were taking too long.

There was no cloud monitoring. No observability dashboard. No automated retry. No Slack notification saying:

🚨 Production indexing failed.

There was just a business preparing to operate and a sleepy Computer Science student eventually realizing:

“Ah... the indexes.” 😅

That was one of my earliest lessons about production systems—years before I knew to call them production systems.

The solution wasn't simply “don't fall asleep”

The obvious lesson would have been: Stay awake next time.

But that wasn't really the engineering lesson. The better question was: Why should an important business process depend on one tired person manually completing everything during the night?

I eventually learned to use the available computers more effectively. Instead of processing everything sequentially on a single machine, I could run independent processing across multiple computers at the same time.

Work finished faster. There was less chance of running out of time. And I learned to verify that the processing had actually completed before the next business day began.

I certainly didn't call this parallel processing, automation, resilience, or reliability engineering at the time. I was just trying to make sure the cashiers worked the next morning. 😄

If an important business process depends entirely on a human remembering to run something every night, eventually that human is going to fall asleep.

Software isn't really about software

There was another lesson hidden in those nightly jobs. The important thing wasn't the Clipper program. It wasn't the index files. It wasn't even the computers.

The important thing was that the business needed to operate the next morning. Cashiers needed to serve customers. Departments needed their systems. Management needed accurate sales information. People depended on technology to do their jobs.

Good software engineering isn't only about making software work. It's about understanding what happens to the business when it doesn't.

I've carried that lesson through many different industries and generations of technology. The systems became more sophisticated. The business dependency never disappeared.

Theory became real

Working while studying also changed how I learned Computer Science. Networking wasn't simply something described in a textbook when I had physically laid network cable and connected machines. Databases and data structures weren't purely academic when business information depended on them.

Programming wasn't merely an assignment when someone needed the system to work. And debugging became much more interesting when you couldn't tell the supermarket: “I'll submit the fix next semester.” 😄

Theory gave me a foundation. Real work gave that theory consequences. The combination taught me faster than either one could have done alone.

I didn't have a 20-year career plan

It's easy to look backward at a career and imagine everything was planned. Mine wasn't.

I wasn't sitting there as a student thinking: Computer Technician → Computer Science Instructor → Web Developer → Entrepreneur → Programmer → Senior Engineer → Technical Lead → AI-Assisted Engineering.

I was mostly trying to solve whatever problem was in front of me. Then I learned something. That knowledge led to another opportunity. That opportunity introduced another problem. And the cycle continued.

The career path only looks organized when you look backward. While you're living it, you're usually just trying to figure out the next thing.

From nightly indexing to modern automation

Today, the technology is almost unrecognizable compared with those early systems. We have background workers, schedulers, CI/CD pipelines, health checks, telemetry, distributed processing, automated retries, alerts, cloud infrastructure, and now AI coding agents.

But underneath all of that technology are many of the same engineering questions I encountered as a student: What happens when this process fails? Who depends on it? How will we know it failed? Can we recover? Can we automate it? Can we design it so one sleepy human isn't the critical dependency? 😄

The tools became dramatically better. The responsibility didn't disappear.

A lesson for students starting today

If you're studying Computer Science today, don't worry about knowing every framework, programming language, cloud platform, or AI tool. You won't. Nobody does.

Instead, look for opportunities to connect what you're learning with something real. Build something. Repair something. Automate something. Help someone solve a problem. Understand how a business operates. Talk to the people who actually use the software. Break something—then figure out why it broke.

Your first experience doesn't need to involve Kubernetes, microservices, cloud architecture, or artificial intelligence.

Mine involved UTP cables, Windows 3.11, Clipper, servers, supermarkets, POS systems, nightly indexing... and occasionally falling asleep. 😄

And somehow, that became the beginning of a career in software engineering.

The tools changed. Learning didn't.

If someone had told that young Computer Science student that one day software could be generated by artificial intelligence—and that part of his job would involve reviewing and directing that generated code—I probably wouldn't have believed it.

But there's something reassuring about looking back. The technologies changed. The fundamentals didn't.

You still need curiosity. You still need to understand the problem. You still need to understand the business. You still need to debug things that don't work. You still need to learn technologies you've never encountered before. And you still need to take responsibility for what you build.

Don't build your career around a technology. Build your ability to learn.
Technologies eventually become legacy systems. The ability to learn doesn't.