Photo by Ashley Batz on Unsplash
I’ve worked in IT for over two decades, but my journey with computers began in the late 1980s. I grew up with cassette tapes, floppy disks, DOS, and writing code line by line — no Google to save me. Before that, I was a kid building radios and circuit boards, tinkering with resistors, ICs, and capacitors. I was troubleshooting and reverse-engineering before I knew the terms.
That shaped a habit that’s rare today: think first, then react. It’s the core of what I call engineering thinking.
When a program crashes and an error pops up, panic sets in. People freeze or click randomly, hoping for a fix. But here’s the thing: the error message often tells you what’s wrong. Slow down, read it, and that small act of patience is usually the solution.
That shaped a habit that’s rare today: think first, then react. It’s the core of what I call engineering thinking.
I’ve supported thousands of applications and devices — accounting systems, ERPs, CRMs, databases, DNS, Active Directory, SharePoint, CAD software, custom builds, networking, routers, firewalls, you name it. Do I know them all inside out? No way. But I get their fundamental purpose. And that’s enough.
It’s about logic, not memorization. Understand what the software or device is trying to do, its expected inputs, and its intended outputs. Then troubleshoot: follow the logic, reverse-engineer the path, and the fix reveals itself. That’s engineering thinking — analyzing, optimizing, and solving through clarity on how things connect.
Fixing IT issues is like fixing a car. Modern vehicles are rolling computers — when something breaks, the check engine light flashes, and a scanner pulls an error code, just like an IT log or exception message.
But pre-computer mechanics troubleshot with logic. No codes — just experience, sharp senses, and system knowledge. They’d hear a weird noise, feel a rough idle, or smell something burning and start reasoning. Ever see a mechanic with a stethoscope? Same principle: know how the system should work, then pinpoint the breakdown.
A good mechanic doesn’t swap parts blindly. They ask:
IT’s the same:
Take routers and firewalls. A connectivity issue might show “connection timed out” or “interface down” in the logs. I’d ask:
It’s about how components work together and where they fail. Programmers lean on these logs to debug; I use them to optimize the whole system. That’s engineering thinking in action.
It’s about logic, not memorization. Understand what the software or device is trying to do, its expected inputs, and its intended outputs. Then troubleshoot: follow the logic, reverse-engineer the path, and the fix reveals itself. That’s engineering thinking — analyzing, optimizing, and solving through clarity on how things connect.
Here’s how systems transform inputs into outputs:
Car
Car
Router
Firewall
IT System
IT System
Learning assembly language in the late ’80s and early ’90s was brutal — complex and unforgiving. But one concept stuck with me: the logic of if → else → then. Not in syntax, but in structure — compare, branch, execute. The foundation of decision-making, stripped to its raw form.
It’s simple yet powerful, stretching beyond code:
I’ve used it to debug software, streamline processes, and make life decisions. It’s my framework for breaking down any problem — IT or otherwise.
Here’s a chuckle: I’m all about logic, but I forget we’re human. Troubleshooting with precision is my thing, yet I need to breathe and notice the emotions in the room. It’s not just a “connection timed out” error — it’s the stress of juggling tech layers and people’s frayed nerves!
The “if-this-then-that” steps can suck you in. But we’re not machines. Sometimes, the real win comes from stepping back, letting instinct kick in, and blending creativity and empathy with engineering thinking. That’s when you see the full picture.
Tech evolves fast — today’s tools are tomorrow’s relics. But the problem-solving mindset? Timeless.
Whether it’s a crashed server, a buggy app, a check engine light, or a tough call — don’t panic. Pause. Read. Think. Grasp the “why.” Everything else falls into place.
And after decades in IT, I’ve learned to laugh at myself too. Logic only goes so far before you realize it’s fine to step back, breathe, and admit we’re all figuring out the machines — and ourselves — one error at a time.
