We Build Things We Can't Touch: On Mental Models in Software Engineering

The Strangeness Nobody Mentions

There's something fundamentally strange about software engineering that took me years to actually sit with: we build things we can't touch.

A computer engineer works with physical components — circuit boards, processors, memory chips. You can hold them, inspect them, trace their connections with your eyes. The hardware is right there, waiting to be understood by direct observation.

Software doesn't offer that. You interact with a device, but the application itself isn't a tangible object. You can't hold a codebase in your hand. You can't watch data flow through a system the way you'd watch water move through a pipe. Everything we build is invisible, and yet we're expected to reason about it with the same precision an electrical engineer brings to a circuit.

So how do you engineer something that doesn't physically exist?

The Answer Is a Model, Not a Tool

I've come to believe a huge part of the answer lies in mental models.

The best engineers I've worked with and learned from don't just write code — they build a rich, accurate representation of the system in their minds. They can visualize how data moves, how components interact, how a change in one module ripples across the whole. They reason about the system's behavior before writing a single line of code, testing ideas against that internal model rather than against the compiler.

This is the difference between stitching together features that "seem to work" and designing a solution that genuinely fits the problem. I noticed this most clearly while building the backend for Vehicash, where a single decision — how GPS-verified check-ins should relate to payment release — touched the vehicle module, the campaign module, and the escrow logic all at once. Writing that code without first holding an accurate model of how those three pieces communicate would have meant discovering the coupling problems in production instead of before I typed anything.

The more precise your mental model, the better you are at debugging, scaling, and evolving what you've built. You're not guessing. You're navigating a map you already hold.

Vocabulary Is Not the Discipline

Early in my journey, I thought software engineering was mostly about mastering languages, frameworks, and tools. React one month, NestJS the next, then whatever the ecosystem decided was essential after that. Over time, I've realized those are just the vocabulary.

The real skill is developing and refining the mental picture of what you're constructing — an invisible architecture that lives in your head long before it lives in production. A framework can hand you conventions and scaffolding, but it can't hand you the judgment to know which module boundary actually matches your problem, or which coupling will hurt you six months from now versus which one is harmless.

At its core, this discipline isn't about moving syntax around a screen. It's about understanding complex systems, building accurate abstractions, and turning invisible ideas into reliable, real-world solutions. The syntax is just how the model eventually gets expressed — it was never the point.

Holding the Map

I don't think there's one correct way to hold a mental model. Some engineers sketch diagrams before touching an IDE. Some write out the flow in plain English, almost like a design doc to themselves. Some keep it entirely in their head and only externalize it when something breaks and they need to explain it to someone else.

What I do know is that skipping this step — jumping straight to code because the tutorial-shaped part of the brain wants to start typing — is usually the more expensive path. The model still gets built eventually. It's just built through debugging sessions and rewrites instead of through deliberate thought beforehand.

I'm curious how other engineers handle this. When you're deep in a project, what helps you build or hold onto that mental model? Do you sketch diagrams, write things out, or keep it all in your head? I'd genuinely love to hear how other engineers approach this.