Engineering Judgment

Make technical decisions from evidence, explicit trade-offs, and the needs of the system.

Judgment is the ability to choose a reasonable action for the current context. It grows through fundamentals, careful observation, feedback, and reflection—not through memorizing a preferred tool.

Frame the problem before the solution

Write a short problem statement that answers:

Who is affected, and what can they not do today?
What evidence shows the size or frequency of the problem?
Which constraints are real: time, safety, cost, compatibility, regulation, or skills?
What outcome would count as success?
What must remain true while the system changes?

“Move to Kubernetes” is a proposed solution. “Deployments block for 40 minutes and fail recovery twice a month” is a problem the team can investigate.

Use a decision record

For a decision that will outlive the current task, record:

Terminal

Context
What is happening and why a decision is needed.

Constraints
Requirements, limits, risks, and assumptions.

Options
The serious alternatives, including doing nothing.

Decision
What we chose and the evidence behind it.

Consequences
What becomes easier, harder, more expensive, or newly possible.

Review
Owner, success measure, and date or condition for reconsideration.

The purpose is not ceremony. It lets a future engineer understand why the current system exists and when the decision should change.

Debug from evidence

State the observed behavior precisely, including time, environment, and scope.
Make the smallest reliable reproduction or query.
Compare a working path with the failing path.
Move through layers in a fixed order rather than changing several things at once.
Form one hypothesis with a predicted observation.
Run the least disruptive test that could disprove it.
Record the finding and restore any temporary diagnostic change.

Do not confuse correlation with cause. A restart that clears a symptom is a recovery action, not an explanation.

Build operational quality into the change

Before merging, ask whether the change has:

clear inputs, outputs, errors, and ownership;
tests at the cheapest useful level;
safe defaults and least-privilege access;
logs and metrics that explain success and failure without leaking secrets;
a deploy, rollback, migration, and compatibility plan;
bounded resource use, timeouts, and failure behavior;
documentation for the next engineer; and
a way to verify the result in production.

Manage uncertainty honestly

Use direct language:

Known: supported by an observation or authoritative source.
Likely: the best current explanation, with stated evidence.
Unknown: material information the team does not yet have.
Assumption: a belief the decision depends on and should verify.

Saying “I do not know yet; I will check these two signals” is stronger engineering than presenting a guess as a fact.

Grow technical depth

Use a repeating loop:

Choose a real system behavior you do not understand.
Learn the underlying model: operating system, network, data, runtime, or protocol.
Apply it in a small task or lab.
Explain it to another engineer and invite correction.
Capture the result in a guide, test, tool, or runbook.

Depth is not knowing every answer. It is being able to find the right layer, ask a better question, and verify the answer.