Ten Years of Work Is Not Ten Years of Experience.

There is probably an engineer in your organisation with four years of experience who is plainly better than someone there with twelve. Not more confident, and not better in interviews — better at the work itself: quicker to the real cause, harder to surprise, right about the design more often than anyone else in the discussion. Everyone can see it. Nobody can quite explain it, so it gets put down to talent and is not examined further.

Talent is the least useful answer available, and it is usually not the correct one either.

The word doing the damage here is experience. Counted on a CV it means time present: you were employed, in that role, for that many years. Everywhere else we use it to mean something earned — that a person has been through things and is different as a result. The two meanings are quietly assumed to be the same, and years are counted as though the second follows automatically from the first. It does not follow, and the gap between the two is what the rest of this is about.

What actually changes you

Think about the last time your engineering judgement genuinely improved. It was almost certainly not the day somebody explained a concept to you. It was a day you were confident about something, acted on it, and discovered you had been wrong — and the discovery arrived close enough to the decision that you could still remember why you had made it.

That is the whole mechanism. A belief you held gets contradicted while you can still see the reasoning behind it. Nothing else does the same work. Reading does not, because reading adds facts without testing any of yours. Being told does not, unless you had committed to a position first.

Experience does not accumulate with time spent. It accumulates with contradictions received.

Which turns the question about experience into a question about arithmetic. Not how many years, but how many times in those years the work came back and told you that you were wrong.

The Tuesday

Here is how those occasions get lost, and it is not dramatic.

You decide, on a Tuesday, that a structure can be freed at the end of the callback. You think about it for under a minute, and everything you can see says you are right: the driver loads, the tests pass, the board runs for a week on the bench. The decision is wrong. Under a timing your bench does not produce, something is still holding a reference.

Eighteen months later, at a site in another country, units begin rebooting every few weeks. A support engineer collects a crash log. It sits in a queue. Eventually somebody looks at it properly, works out that a structure is being touched after it was freed, finds the path that does it, and fixes it in an afternoon. That engineer learns something real that day, and they learn it because they are the person who found out.

The loop did close. It closed for somebody else.

It never closed for you. Nobody told you, because by then there was no reason to connect the fix to you and no way to do it. And in those eighteen months you made the same kind of decision perhaps forty more times, at the same speed, with the same confidence, on the same evidence: nothing had ever come back to suggest you were getting it wrong.

Nothing about that story requires anyone to be careless. The bench was reasonable. The tests were reasonable. The support process worked exactly as designed. The decision still cost you the correction, and the correction went to a stranger. Eighteen months of experience were added to your CV. None were added to your judgement.

Why you cannot feel the difference

You might expect a missing correction to feel like missing information. It does not. There is no gap where it would have been, no reminder, nothing in the tree to grep for.

An unclosed loop does not feel like a gap in your learning. It feels like confirmation.

Worse, the effect is not evenly spread. It is worst exactly where you can least afford it. Small decisions are corrected constantly: a syntax error in seconds, a failed test in minutes, a review comment in a day. Large decisions are barely corrected at all, and the interface you chose or the layering you settled on may never report anything.

The quality of your feedback is inversely related to the importance of the decision it concerns.

So the confidence you carry about your own judgement has been assembled almost entirely out of the decisions that were easy to check. It feels like one continuous sense of competence, and it is not. It is reliable about syntax and largely untested about architecture.

This is also the answer to the question we started with. The engineer with four years was somewhere the loops closed quickly — a small team shipping often, a maintainer who reviewed strictly, a product whose failures came back within weeks and reached the person who caused them. Twelve years of specifying, handing over and moving to the next project delivers very few contradictions, and the person who lived through it has no way of knowing that is what happened. Those years were not wasted; exposure teaches a good deal on its own. But exposure without a returning signal produces familiarity rather than judgement, and it is very hard to tell those two apart in yourself.

Years accumulate on their own. Judgement only accumulates when the result reaches the decision that caused it.

Going to look for it

If the work will not reliably tell you when you were wrong, the remaining option is to go and find out on purpose. It is a disposition rather than a technique, and it shows up in three ordinary places.

• Commit to a prediction before you look. Before the print, before the trace, before running the test: write down the value you expect and why. It costs ten seconds and it is uncomfortable, which is the point. A prediction you kept in your head will always seem correct afterwards, because you quietly adjust it to match what you found. A written one cannot be adjusted.
• Go and find the consequences that were routed away from you. Read the support tickets for the products you have worked on, including the ones assigned to other people and the ones from two years ago. Almost nobody does this, because nothing requires it and it is not comfortable reading. It is the only way to see the results of decisions you have been repeating ever since you made them.
• Notice how long it has been since you were proved wrong. Not corrected on a detail — proved wrong about something you were confident in. If you cannot remember the last occasion, the likely explanation is not that you have stopped being wrong.

It is also worth knowing what quietly lowers your rate. Moving into a role where you specify rather than build. Working on a product whose failures reach a support team instead of a developer. And, more recently, accepting generated output that works: you predicted nothing, so nothing was contradicted, and you end the day exactly as sure of yourself as you began it. This matters most where a wrong answer looks exactly like a right one until the timing changes, which is the same reasoning behind deciding when to attempt something yourself and when to go straight to the answer.

The opposite is what makes an experienced colleague worth so much, and it has little to do with what they know. Their value is timing: they tell you the approach is wrong while you still remember the reasoning that produced it, which is the only moment at which being told changes anything. Months of delay become seconds. It is why we run sessions live rather than as recordings, and why they are built around working through problem scenarios with attendance enforced.

So there is a question worth putting to yourself at the end of a year, and it is not whether you feel more capable than you did. Confidence will answer that one dishonestly. It is whether you can name three occasions when you found out you were wrong, and what you had to do to find out. If they come to mind easily, you gained a year of experience. If you have to search for them, you may only have gained a year, and silence is not the same thing as being right.

— Raghu Bharadwaj