The Hardware Mind: Signal Routing vs Object-Oriented Programming

For a very long time, I wanted to work in robotics and hardware. Electricity, signals, and logic gates always made intuitive sense to me. My favorite puzzles in video games have always been signal modulation puzzles—especially when the feedback makes a physical sound. There is something incredibly satisfying about physically routing logic.

But I never pursued it. In high school, my math grades hovered around a D-C average. Because the traditional academic framework equated “bad at math” with “unintelligent,” I internalized the idea that I was simply too dumb to build robotics.

It took me over a decade to realize my failure wasn’t a lack of logic. It was the burden of symbolic overhead. Math classes required me to memorize an ocean of abstract symbols, and worse, the key metric for success was always quick recall. When your brain physically maps out problems through spatial circuit routing, flashcard-speed recall is an impossible metric.

My brain does not process information abstractly. It processes information physically. When I debug code, I am not reading an instruction manual—I am looking at a circuit board. I see inputs routing through logic gates (if == true goes left, if == false goes right). A function call isn’t an abstract command; it’s a nested microchip pulling the signal deeper into a smaller block, processing it, and pushing it back out.

Failing Object-Oriented Programming (OOP)

This physical, systems-based intuition is exactly why abstract software curriculum constantly tripped me up. I don’t naturally think in Object-Oriented Programming (OOP), nor do I strictly think in modern Unity Components (though Components are much closer).

A perfect example of this disconnect happened in 2021 when I was interviewing for a Game Designer position at Hypixel Studios. The role also required C# programming, and during the technical portion, I was given a classic OOP question: “What is in a block?”

The interviewer was testing my ability to isolate a clean abstraction boundary. As a programming question, they likely wanted a crisp separation of architecture.

Instead, I answered the question by mashing the abstract structure together with the literal game design systems. I told them: “It inherits from a parent block class, and it has a destroy method that leaves an animation effect… but it also holds the integer of what needs to be hit, its spatial transform, its loot based on loot chance and type, and the materials it drops…”

I don’t actually know if I failed the question, but the disconnect was obvious.

To a traditional C# programmer, I blurred the line of abstraction. But to my mind, I was answering as a systems designer. You can’t separate the destroy() method from the physical integer that triggers the block’s death or the coordinate transform where it sits. I didn’t see the block as a floating concept of data structure hierarchy; I saw it as a physical data knot in the world where state, signals, and methods are inextricably wired together.

It’s Not OOP, It’s Physics

When I architect software today, I am fundamentally not doing Object-Oriented Programming.

Instead, I am building physical circuitry. The code is the street, the logic gates are the intersections, and the data is the energy running through the system. My code is structured entirely around topological tension, field interactions, and signal routing.

It isn’t a massive “eureka” moment. It’s just a quiet realization that the things I’ve passively loved and held onto for years—like circuitry and signals—have actually been the exact framework powering my logic all along. High school math simply didn’t have the vocabulary to grade it.