Engineering Judgment

Most of what we learn in school and early careers is syntax, frameworks, and algorithms. Nobody teaches you the non-obvious stuff directly, the skills that actually separate good engineers from great ones. You accumulate them through years of debugging things that shouldn't be broken, building things that turned out to be the wrong thing, and working with people who were better at this than you.

These habits are how that judgment gets built.

Know how to find what you need

Computing is made possible by countless layers of abstraction. When something breaks, you need to surface information from the right layer, which requires understanding which layer you're actually in.

The most common debugging mistake is trying to fix a problem in the wrong layer entirely. An error message points you somewhere. You spend hours there. The problem was upstream.

Becoming good at this means developing a map of the spaces you typically work in, the spaces adjacent to them, and the signals that tell you you've crossed a boundary. Nothing is worse than trying to debug an application problem when the real issue is the framework, or debugging the framework when it's the network, or debugging the network when it's your assumptions.

This skill compounds. Every time you trace a problem through a layer you've never visited before, you build your map. After a decade, you have a lot of map.

Know when you're solving the wrong problem

This is different from building the wrong thing. Solving the wrong problem means you've understood the task correctly but misunderstood where the actual breakdown is.

The error message points you at X. You spend three hours on X. X is a symptom. The real problem is in Y, which you haven't looked at yet.

The correction is a habit more than a skill: before going deep, zoom out. What would have to be true for this error to appear? What are all the places that could produce this behavior? Only then, pick the most likely one and start there.

The engineers I've worked with who are most dangerous at debugging have this habit so deeply embedded they barely notice they're doing it. They pause before diving. They ask "what would need to be true?" before they ask "what is happening?"

Know how to tell yourself a story

Mental modeling is underrated. The difference between debugging with intention and debugging by trial and error is whether you have a falsifiable hypothesis.

Great engineers narrate to themselves as they work: I think the problem is X. If I'm right, then Y should be true. Let me check Y. This is different from guessing. You're building a model and then testing it. When the test fails, you update the model. When it succeeds, you keep going.

This sounds obvious. It isn't, for most people. The natural instinct when stuck is to try things, different things, any things, until something changes. That produces a lot of noise and very little signal. Forced narration slows you down briefly but gets you to the answer faster because you're learning something from every test instead of just rolling dice.

Know when to ask for help

This is one of the hardest skills to calibrate, and the calibration is personal. There's no rule that works for everyone.

Ask too soon and you rob yourself of the discovery that comes from struggling with a problem long enough to actually understand it. Ask too late and you waste days.

The right moment, for me, is when I've exhausted my own model. Not when I'm stuck, exactly, but when I've developed a hypothesis, tested it, been wrong, developed another one, tested it, been wrong again, and now I can't generate a new hypothesis that seems worth testing. At that point, what I need is someone else's model, not my own continued application of mine.

The useful question to ask at that point isn't "can you help me fix this?" It's "here's what I understand, here's what I've tried, here's where my model breaks down. What am I missing?" That question respects both people's time and produces better answers.

Know how to keep the big picture while working in the details

The ability to zoom out is rare and valuable. It means remembering why the thing you're building exists, and what it's supposed to do for people, while you're knee-deep in an implementation detail.

Engineers who lose this deliver technically correct solutions to the wrong problem. They'll refactor a module to beautiful clarity and in doing so miss that the module's behavior was quietly keeping a crucial invariant that now no longer holds. They'll hit every spec and not notice that the specs were incomplete.

The habit I've found useful: every hour or so, lift your head. Re-state in one sentence what you're actually trying to accomplish. Not the implementation goal ("I'm making this function return early when X") but the product goal ("I'm trying to make this form not lose the user's input on validation failure"). If those two things have drifted apart, now is the time to notice.

None of these are technical in the narrow sense. No framework, no algorithm, no language feature. They're all, at some level, about how you hold your attention: what you keep in focus, what you keep checking, when you pause.

That's mostly what good engineering is, in the end. Not knowing things. Knowing how to think when you don't know things.