Know What You’re Building. Prove That It Works.

When I think about the best engineers I’ve worked with and the engineers I want to hire, it increasingly comes down to two things.

1. Can they define what they’re actually trying to build?
2. And can they prove that their solution works?

Neither of these is new. They mattered when engineers wrote every line themselves, and they matter just as much when agents are writing more of the code. The tools and mechanics of building software will keep changing. These two things don’t.

Know what you’re building. Prove that it works.

To me, these are two of the clearest differences between engineers who primarily produce code and engineers who drive outcomes. I find it useful to boil the job down this way because both are easy to say yet easy to underinvest in.

Know what you’re building

A lot of software work starts with an input, not an outcome. A ticket, a customer request, a rough idea, a problem to solve. We often move from that input straight into implementation before we have a clear enough point of view about what good should actually look like.

Strong engineers are good at turning ambiguity into something concrete.

They can take an unclear problem and form a point of view about what the solution should do, how it should behave, and what success should look like. They figure out what matters, what doesn’t, and what needs to be true for the solution to work.

That does not mean having perfect requirements before starting. Usually, you won’t. The real skill is being able to iterate toward the answer. Build something. Look at it. Decide what is right and what is wrong. Refine the direction. Repeat.

The important part is having enough clarity and judgment to keep moving toward something better. You do not need to know every detail up front, but you do need to recognize when the work is moving in the right direction, when it is drifting, and when your understanding of the problem needs to change.

That is what I mean by knowing what you are building. Not having every answer before you start, but being able to develop a clear point of view and continuously sharpen it as you go.

Prove that it works

This goes beyond whether the code runs or the feature has shipped. Did it solve the problem? Is it reliable? Does it behave the way we expected? Are people using it? Did it improve the thing we set out to improve?

The next step is looking for proof.

Sometimes that proof is technical: tests, logs, error rates, performance, failure modes. Sometimes it is product evidence: usage, adoption, customer behavior, support volume, or direct feedback. What counts as proof depends on what you built and what you were trying to accomplish.

Too often, we stop at “shipped.” But shipping is not proof. In many cases, it is the point where the most useful evidence starts becoming available.

Proof is not a one-time event. A solution can work today and degrade tomorrow. Adoption can grow or stall. Reliability can change as usage increases. Assumptions that looked right at launch can turn out to be wrong once the software meets reality.

This is where ownership shows up most clearly. Strong engineers stay close enough to what they build to understand what happens after it ships, learn from the evidence, and adjust when reality does not match the expectation.

The point is not to measure everything. It is to know what evidence matters and keep paying attention to it.

“Looks good to me” is not proof. Neither is “the ticket is done.” And “the tests pass” is often only one piece of the evidence.

You should be able to answer a much more useful question: How do you know? And then show it.

Code vs. Outcomes

I want engineers to care about craft. Good code matters. Maintainability matters. Design matters. Quality matters. There is nothing wrong with taking pride in the thing you built.

But the code is not the outcome.

As engineers, we can get so focused on the pursuit of better code that we lose sight of what the code was supposed to accomplish. We refine the abstraction, rework the architecture, improve the implementation, and sometimes keep polishing long after the outcome is already good enough.

Heck, I’ve been guilty of this plenty of times in my career, and I still catch myself doing it. There’s a real satisfaction in landing on an implementation that feels clean, elegant, and just right.

The strongest engineers I have worked with keep the craft in service of the outcome. They still care about the implementation, but they know when better code meaningfully improves the result versus when it is just better code.

That is the distinction I care about most: not engineers who simply produce code, but engineers who take ownership of outcomes.

This was always true

None of this is new.

Good engineers have always needed to know what they were building and prove that it worked. We may have spent more time talking about implementation because implementation consumed so much of the work, but it was never the whole job.

What is changing is how obvious that is becoming. As agents take on more of the implementation, it becomes harder to confuse producing code with producing value. That is true whether you write every line yourself or use an agent to help. The tools will keep evolving.

Know what you’re building. Prove that it works.