Judgment is what separates a good software developer from a merely competent one. It isn't typing speed, tool fluency, or the length of the framework list on a résumé. Two developers can ship the same feature in the same sprint and produce work that ages very differently over the next three years. One version absorbs new requirements as they arrive. The other gets rewritten.
The code often looks similar on the day it merges. What sets the two apart is a set of decisions made before the first line was written, during review, and in the conversations with people who never opened the pull request. Judgment is a career-length skill, and it develops in stages. The sections below walk through those stages in the order they tend to show up.
Before the Code: Reading the Problem, Not Just the Ticket
Competent developers start with the ticket. Good ones start with the problem behind it. That sounds like a semantic difference until you watch the two approaches play out over a quarter.
The ticket-first developer builds exactly what the description says and then discovers, in QA or in production, that the description missed something a stakeholder assumed was obvious. The problem-first developer asks two or three questions up front, and half the time those questions change the scope.
Good developers build this habit deliberately, and there is evidence behind it. An empirical comparison of decision-making skills found that developers tend toward more vigilant decision-making than non-professionals, searching more intensively for alternatives and evaluating them more carefully.
The good ones lean into that tendency. A ticket is a hypothesis about what the user needs, not a specification. Much of what separates strong developers from the rest shows up in this first hour, before any code is written.
The AI tooling that arrived over the last few years has sharpened this divide rather than erased it. A junior developer with a capable assistant can now produce a plausible first draft of almost anything. The judgment question is whether that draft is solving the right problem.
In practice, the productivity gains from AI coding assistants tend to concentrate in less experienced developers, while senior developers who know a codebase well often see little measurable speed-up. Senior developers aren't slower because they're worse at the tool. They're slower because they're doing work the tool cannot do: deciding what should exist in the first place.
During Review: The Comment That Reveals Everything
Code review is where judgment becomes visible to the rest of the team. A competent reviewer catches syntax issues, flags obvious bugs, and asks for tests. A good reviewer does all of that and then asks the question nobody else asked: why does this exist? Or: what happens when the assumption in line 47 stops being true?
The best reviewers develop a small handful of moves they use consistently:
- Name the trade-off. Every non-trivial change has one. Saying it out loud ("this is faster but harder to debug") gives the author a clean choice instead of a vague objection.
- Separate blocking from noting. A review that mixes must-fix issues with style preferences trains the author to skim. Mark which is which.
- Ask before rewriting. Suggesting a full rewrite in a comment thread is usually a sign the conversation should have happened before the pull request opened.
- Approve with notes when it's close. Blocking a PR over a preference costs the team more than the improvement is worth. Reserve the block for real risk.
This is also where the good developer's restraint shows up. A well-known observation from the field is that seniority often looks like removing code, not adding it, and understanding that some problems don't need a code solution at all. That instinct is disproportionately valuable in review, where the loudest voice is usually the one asking for more.
The Habits That Compound Over a Decade
Judgment is not built in a sprint. It comes from small habits repeated for years, most of them unglamorous:
- Write it down. Design docs, decision records, post-incident notes. Not for the audience, but for the version of you who has to revisit this in eighteen months.
- Read code you didn't write. Reviewing unfamiliar systems, reading open-source projects, and pairing on other teams' problems builds the pattern library that judgment draws from.
- Own the thing after it ships. Developers who never see their code in production never learn which of their instincts were right.
- Track your own mistakes. The reason senior engineers make fewer bad calls is that they've cataloged their old ones.
None of these habits show up in a performance review the month you start them. They compound. Five years in, the developer who kept design notes can tell you why the auth system looks the way it does. The one who didn't is guessing along with everyone else.
The good news is that judgment is teachable, and it's mostly taught by exposure. Sitting next to someone who has made the hard calls, watching how they weigh options, and being asked to defend your own choices out loud does more than any course. Competence gets you hired. Judgment is what makes the next ten years of your work worth something to the people who depend on it.