Know Yourself

Your pattern follows you. It doesn't care what domain you're in.

The Pattern That Follows You

You have a way of approaching problems. A pattern. It's been with you longer than you realize.

The way you debug code is the way you troubleshoot a car. The way you plan a project is the way you plan a trip. The way you learn a new framework is the way you learn anything.

This pattern transferred from domain to domain before you were an engineer. It will follow you to whatever comes next.

Know your pattern. It's your most valuable asset and your most persistent liability.

Model-Builders vs. Fast Executors

Some people receive a briefing and start executing immediately. They trust the information, accept the constraints, and move. Fast. Efficient. Decisive.

Others need to build their own mental model first. They poke at the problem. Test hypotheses. Be wrong a few times. Only then do they move, but when they move, they move with understanding.

Neither is better. Both have costs.

Fast executors risk building on shaky foundations. They might solve the wrong problem efficiently.

Model-builders risk spinning too long. Analysis paralysis. Perfecting the plan while the window closes.

Which are you? Not which do you want to be. Which are you actually, when you're tired, when you're pressured, when no one's watching?

Your Failure Mode

Every engineer I've worked with has a default failure mode. The thing that goes wrong when things go wrong. The diagnostic has three core readings:

Ship too fast. You skip preparation. You don't fully understand the problem before you start solving it. You ship, then discover you built the wrong thing, and the rework costs more than the preparation would have.

Ship too slow. You can't define done, so you never get there. You're waiting for confidence that won't come, and the work expands to fill whatever time is available.

Oscillate. You swing between the two. Ship too fast, get burned, over-correct to shipping too slow, miss a deadline, panic, ship too fast again. The pendulum never settles.

There are more elaborate patterns behind these (the gold plater, the hero, the one who rewrites everything they inherit), but they resolve to the same common thread: you're checking feelings instead of criteria. "Does this feel done?" is the wrong question. "Does this meet the acceptance criteria?" is the right one.

The Feelings Trap

Feelings lie.

When you're excited about a solution, it feels done. It isn't. You're high on the dopamine of solving the puzzle. You haven't checked if it actually works.

When you're uncertain about a solution, it feels not done. It might be. Uncertainty is not evidence of incompleteness. Sometimes the uncertainty is just... uncertainty.

The fix: Define done before you start.^[1] Write it down. One sentence. "This is done when ___."

Then check the criteria, not your feelings. Does it meet the criteria? Ship it. Does it not? Keep working. Your feelings are not invited to this decision.

Build Guardrails

Once you know your failure mode, build guardrails against it, while you're calm, aimed at the moment the pattern takes over.

If you ship too fast: write down what done looks like before you start, and make review a required step, not an optional one. If you ship too slow: timebox discovery, define "good enough" in writing, and ship earlier than comfortable. If you oscillate: notice which mode you're in right now, and run the same checklist every time, no exceptions.

The shape is the same for any pattern, including the fancier ones: a mechanism you set up in advance that catches you at the moment feelings would otherwise decide.

The guardrails don't fix the pattern. They manage it. You're not trying to become a different person. You're trying to catch yourself before the pattern causes damage.

And self-awareness is built, not natural. After each project, ask: too fast, too slow, or about right, and what led to it? Then ask someone you work with what it's like to work with you. Listen. Don't defend. Take notes.

The Pattern Across Domains

That aircraft maintainer troubleshooting a hydraulic failure is using the same pattern they'll use debugging code. Gather information. Form hypotheses. Test. Isolate. Fix. Verify.

That recruiter matching candidates to roles is using the same pattern they'll use in system design. Understand requirements. Understand options. Find the fit. Manage tradeoffs.

The domain changes. The tools change. The pattern doesn't.

This is why you can move between industries, between languages, between paradigms. The specific knowledge is learnable. The pattern is transferable.

It's also why your failure mode follows you. It doesn't care what language you're writing. It doesn't care what industry you're in. It's yours.

The Work of Knowing Yourself

Knowing yourself is not a one-time revelation. It's ongoing work.

You'll discover new patterns. You'll find failure modes you didn't know you had. You'll think you've fixed something, only to watch it resurface under pressure.

This is normal. This is the work.

The goal isn't to become someone without patterns or failure modes. The goal is to know them well enough to work with them. To catch them before they catch you.

Know your pattern. It's been with you your whole life. It will be with you for the rest of it. You might as well understand it.

Your pattern follows you. Your failure modes follow you. The question isn't whether they exist; it's whether you know them well enough to manage them.