There’s a memory I carry with a lot of fondness: sitting on a bench at my technical school, graph paper on the desk, pen in hand — no computer in sight. The teacher had written a snippet of C code on the blackboard and the task was simple: trace the execution. Variable by variable, call stack by call stack, by hand.

That hooked me instantly — and changed the way I think about everything.

Back in 2012, the computer science technical program gave me something that took me years to name: the obligation to understand what the machine actually does, not just what I want it to do. C doesn’t forgive empty abstractions. Wrong pointer, segmentation fault. Wrong logic, undefined behavior. I learned early that computers are literal — and that this literalness is, at the same time, the greatest source of frustration and beauty in the field.

When I started university in 2016, that seed had already been planted. And college gave me something few environments offer: the freedom to solve classic problems however I wanted, within the constraints imposed on me.

It was in an embedded systems course that things got serious. The proposal was to implement solutions to classic concurrent computing problems — Dining Philosophers, Traveling Salesman — on hardware with limited resources. No infinite swap, no magic framework. Just the problem, the compiler, and the microcontroller in front of me.

That brought me close to territory that many software developers treat as an infrastructure detail: operating systems, process scheduling, inter-machine communication. I learned that understanding where code runs is just as important as understanding what it does. And that computer networking isn’t the layer that shows up when everything is working — it’s the layer that shows up when something breaks.

Today, when I need to debug a distributed integration that fails intermittently, or when I’m designing a solution that will span three services and several databases, I notice that foundation makes a difference. Not because I know everything, but because I know the right questions: what can fail here? Where is the state? Who is responsible for this delivery?

The quality turning point in my code happened when I started working in real enterprise environments.

Before, I wrote code to solve the problem. After a few months on a team, I realized I was writing code to present the solution — and that distinction is enormous. When you know someone is going to read what you wrote, that a colleague is going to open your PR and form an opinion, something changes. You stop naming variables with abbreviations. You start breaking up functions that are too large. You write the comment the next developer will need, not the one you already know.

The first time a more experienced developer pointed to a PR of mine — not for what it delivered, but for how it was written — and said it was good, I understood I was on the right track. Not chasing approval, but finding confirmation that the care I was putting into the craft actually meant something.

Around that time I went deep into the work of Robert C. Martin and Martin Fowler. Refactoring, clean code, SOLID principles — not as dogma, but as vocabulary. A way to name what I already felt intuitively, and a framework for making better decisions when intuition wasn’t enough.

What those authors gave me, more than techniques, was an attitude: code is a means of communication between developers. The machine executes anything that compiles. The one who needs to understand what you wrote is the human who will maintain it in production at three in the morning, six months later — and that human is often yourself.

Today I carry that into the code reviews I do on my team. Not as someone who criticizes, but as someone who believes that well-delivered feedback on a PR has more impact than hours of documentation written afterward. That a culture of care for code is built in the small daily decisions: the variable name, the function that does one thing, the test that documents the intent.

I don’t have perfect code — nobody does. But I believe the pursuit of it is what separates software that ages well from software that becomes technical debt.

And I still prefer to understand what the machine is actually doing.