Ten years in tech are not always ten years of experience
Counting years at a company is a poor way to measure software experience. What matters is which different problems you actually solved.
On this page›
For a long time I measured my career in years at a company. If someone asked how long I had been doing this, I answered with a number. It sounded like evidence. Looking back, several of those years were the same task with a new date on it.
There is nothing wrong with that. Some work deserves to be repeated. The mistake is treating the number as a measure of what you know.
Years measure the calendar
A year in software engineering is a unit of time, not a unit of learning. Learning shows up when the shape of the problem changes and you do not already have the reflex to solve it.
If March's ticket looks like October's, the calendar moved and your judgment did not. You can get faster. You can learn the internal names of the system. That is familiarity. Familiarity is not experience.
The experience that transfers is the kind that helps you decide the next time something is not in the manual: what to cut, what not to build, who to tell before the incident belongs to everyone.
Two people, ten years
Picture two profiles with the same seniority line on a résumé.
The first has spent ten years on the same kind of system. They arrive, take the ticket, close it, ship. They know the repository better than anyone. Ask them where a failure lives and they can point. Ask them for something off that track and the method is the one they already have: the same database, the same way of splitting the problem, the same hurry to get back to what they know. Ten years. Year two already looked like year ten.
The second person has also spent ten years, and not necessarily at ten companies. What changed was the problem. A system with real users. A deploy that failed on a Friday. A domain they did not understand: payments, data, a business constraint that another component would not dissolve. Years of explaining a decision to someone who does not write code, and years of meeting their own design again six months later.
Both can be called senior. One repeated a craft until it was comfortable. The other collected scars that move to the next system.
What the research actually says
Anders Ericsson described this in the work on deliberate practice: expert performance does not come from repeating what you can already do. It comes from working at the edge of what you cannot do yet, with a clear signal of whether it worked. Ten thousand hours of the same hour do not make you an expert. They make you fast at that hour.
Daniel Kahneman and Gary Klein reached a similar conclusion from another direction. Experience improves judgment when the environment is regular enough and the feedback arrives soon and without ambiguity. A chess player sees the result of the move. A lot of software teams do not. The ticket closes, the user leaves, and nobody tells you whether the decision was good or merely quiet today.
Without that signal, years feel like experience and are memory. You remember how it was done last time. You did not learn whether it should be done that way.
Anders Ericsson, the researcher behind deliberate practice, explains the idea himself in under four minutes:
You do not have to quit to learn
If the role no longer stretches you, changing companies is an option, not the only one. Sometimes it is enough to ask for another project, another part of the system, or a problem you do not yet know how to solve.
That looks ordinary from the outside. Volunteer for the incident nobody wants. Write down the flow that currently lives in one person's head. Take a product constraint and propose what not to build. Mentor someone and notice that you cannot explain why the team works this way.
Comfort is not a moral failure. It is a bad growth metric if you confuse it with seniority.
If you hire
Years in a seat say little. What someone solved says more.
Ask about a system that got hard, not for the technology list. Ask what changed in the second version. Ask which decision they would not repeat. A person with four years and three different problems can tell you more than a person with ten years and one well-rehearsed lane.
Tenure does one useful thing: it tells you they did not start last month. It does not tell you what they learned while they were there.
When was the last time you actually felt yourself learning at work? If you cannot remember, the calendar is running on its own.
“Experience is not what happens to a man; it is what a man does with what happens to him.”
— Aldous Huxley, Texts and Pretexts (1932)
References
- Ericsson, K. A., Krampe, R. T., & Tesch-Römer, C. (1993). The role of deliberate practice in the acquisition of expert performance. Psychological Review, 100(3), 363–406.
- Kahneman, D., & Klein, G. (2009). Conditions for intuitive expertise: A failure to disagree. American Psychologist, 64(6), 515–526.
- Deliberate practice, Wikipedia.
- Video: The New Science of Expertise: Anders Ericsson, Rotman School of Management.
> What did you think?
> Thread [00]
moderatedLoading replies…