How Should a Programmer
Measure a Year?

A promotion is an organizational outcome, not the sole measure of professional growth. What is worth measuring over time is the range of problems you can take on, the people who do better work because of you, the team outcomes you help make possible, and the judgment you develop under complexity and uncertainty.

Part I · We need a measure beyond promotion

01What people were really asking in a performance conversation

The musical Rent asks how a year in a human life should be measured: in time, in journeys, or in moments that matter. At work, we tend to offer a more practical answer—salary, level, and promotion.

During performance conversations in 2018, several people on my team raised questions about career development. One wanted to deepen his technical expertise. Another was considering management. Others wanted their technical decisions to carry more influence across the team.

Their aspirations were different, but the anxiety underneath them was similar: how do I know I am progressing? If I am not promoted this year, was the year unsuccessful?

I responded with questions of my own:

• What exactly do you want to become better at, and what should you be able to do a year from now that you cannot do today?
• If you want technical influence, where should that influence come from? Does it require a title first?
• If you are not promoted but learn to solve problems that used to defeat you, does that count as growth?
• If you are promoted but continue repeating the same familiar work, does that count as success?

The room became quiet. The problem was not a lack of ambition. It was that few people had built a way to observe growth other than promotion.

02Promotion is a lagging signal, not a daily yardstick

Promotion matters. It brings recognition, compensation, responsibility, and opportunity. But it is also the outcome of many conditions: available roles, team structure, business timing, and whether a person’s capability has remained visible long enough. It arrives late, and it is never entirely under individual control.

If our sense of accomplishment depends on that single outcome, professional life becomes a long wait. The work in between seems not to count; only the day of the announcement feels real.

A more durable approach is to treat promotion as a lagging signal. It can confirm a period of growth, but it does not create that growth. The daily evidence lies elsewhere: clarifying an ambiguous requirement, handling a production incident independently, designing something the team can understand and maintain, or recognizing that your own plan was wrong and leading the correction.

Part II · Become a professional others can rely on

03In the first three to five years, growth is loud

Early in a Java developer’s career, progress is easy to hear. Yesterday’s baffling stack trace becomes today’s obvious clue. You deploy to production for the first time, investigate a slow database query, and discover that code that runs is not necessarily good code.

The transition from graduate to trusted professional usually takes several years of study and real project experience. In 2018, I called the first three to five years Phase I. Its purpose was not the quickest possible title, but a sufficiently strong foundation.

The list clearly belongs to 2018, when the SSH stack remained common and we moved between official documentation, technical blogs, and Stack Overflow. The deeper point is less dependent on a particular technology: a craft has to be practiced until it works under real conditions, not only in tutorials.

04The first resource you learn to manage is yourself

At this stage, differences in early opportunity are often less permanent than they appear. A gifted engineer might take on senior work in three years; another may need five or six. Across a long career, that gap can often be narrowed through deliberate learning, difficult projects, and honest reflection.

What matters is not who memorized a framework first, but who learned to manage their own work reliably: keeping commitments, studying when the problem is unfamiliar, retaining lessons after a project, and refusing to repeat the same mistake indefinitely.

Some people follow strict study plans. Some are pulled early into painful but important projects. Others advance quietly by making every delivery more dependable than the last. Their routes differ, but they do not wait passively for the organization to manufacture their capability.

Part III · From personal output to team outcomes

05Ten years of experience does not compound by itself

Between five and ten years after graduation, the anxiety often changes shape. Technology continues to move, younger colleagues arrive, and fluency alone no longer feels sufficient. What looks like anxiety about age is often a change in what organizations expect from experienced professionals.

A newcomer first has to prove that they can complete work. An experienced engineer faces different questions: Can you define the work? Can you make tradeoffs with incomplete information? Can you notice when the team is solving the wrong problem? When the result is poor, can you take responsibility and organize a correction?

Time gives us more experience, but it does not automatically turn experience into judgment. Ten years spent confronting different problems can look much like one familiar year repeated ten times on a résumé, yet produce a very different kind of capability.

06Influence does not begin with a title

Someone on my team once said he wanted to make technical decisions and influence more people. I asked whether he had to become an architect or technical lead before influence was possible.

A position grants authority, but not credibility. Durable technical influence grows from simpler evidence: seeing a risk early, explaining complexity clearly, proposing designs that survive contact with production, and correcting your own mistakes when they do not. People listen because your earlier judgments have earned their trust.

Influence is also more than persuading others to accept your design. Its mature form helps a group make better shared decisions: writing down hidden knowledge, explaining principles, making disagreement safe, and helping younger engineers understand why—not only how.

07A technical leader has to see beyond the code

In the original essay, I called the second-stage professional a “team contributor.” This might be a people manager, architect, or senior individual contributor. The common shift is that value no longer equals the amount of code personally produced. It includes making it easier for a group to achieve the right outcome.

You may need to explain an uncertain direction to a manager or investor, secure people and funding, and translate market change into a model that product and engineering can share. After business design come architecture, interfaces, implementation, testing, and release. Anything left unclear at one layer returns later as rework, conflict, or incidents.

Managers should understand whether a team is creating value worth the organization’s investment. Yet people are not line items, and value does not exist only inside a quarter. The difficult responsibility is to protect short-term outcomes, long-term capability, and team health at once.

Part IV · Capabilities you cannot cram for

08Books are maps; practice gives you a feel for the terrain

To preserve the 2018 essay as a record of its time, here is the full reading list I included then. The old retailer links, internal images, and expired web pages have been omitted.

The original 2018 reading list

1. Java and programming fundamentals: Bruce Eckel, Thinking in Java; Joshua Bloch, Effective Java.
2. Code quality: Martin Fowler, Refactoring: Improving the Design of Existing Code; Steve McConnell, Code Complete; Jon Bentley, Programming Pearls.
3. Application frameworks and data: Spring in Action, Spring Boot in Action, and Java Persistence with Hibernate; along with database tuning, caching, NoSQL databases, logging systems, and related topics.
4. Systems design and algorithms: Systems Analysis and Design Methods, Design Patterns, Requirements Analysis and System Design, Object-Oriented Analysis and Design with Applications, The Unified Modeling Language User Guide, and Introduction to Algorithms.
5. Problem discovery and technical leadership: Gerald M. Weinberg, The Secrets of Consulting, Exploring Requirements, An Introduction to General Systems Thinking, and Becoming a Technical Leader.
6. Business, communication, and influence: frameworks such as TOGAF, NGOSS, and ITIL; Barbara Minto, The Pyramid Principle; Drew Fudenberg and Jean Tirole, Game Theory; Robert B. Cialdini, Influence.
7. Domain modeling and architecture: Eric Evans, Domain-Driven Design; Vaughn Vernon, Implementing Domain-Driven Design; Martin Fowler, Patterns of Enterprise Application Architecture; George Fairbanks, Just Enough Software Architecture.
8. Projects, teams, and the human side of software: A Guide to the Project Management Body of Knowledge (PMBOK Guide) and Agile Software Development; Frederick P. Brooks Jr., The Mythical Man-Month; Gerald M. Weinberg, The Psychology of Computer Programming.

Books matter. Weinberg’s work on consulting, requirements, and systems helps us understand problems before rushing to solve them. The Pyramid Principle and Influence sharpen communication. Domain-driven design and architecture books help a team turn business ideas into structure. The Mythical Man-Month, agile literature, and The Psychology of Computer Programming remind us that software has never been only about code.

Reprinting this list is not my way of assigning eight sets of homework to younger engineers. A better approach is to start with a problem you genuinely own. If the code has become painful to change, return to Refactoring. If the team cannot agree on the meaning of its core business concepts, study domain modeling. If projects keep slipping, reread The Mythical Man-Month. When you read with a live problem in mind, ideas are less likely to remain polished vocabulary.

Books can give us concepts. Real capability is built in practice: trying to persuade someone and discovering a hole in the argument; building an elegant architecture that the team cannot maintain six months later; assuming customers want more features when what they really want is one fewer opportunity to make a mistake. Reading gives us language. Practice teaches us when that language holds and when it does not. Return to the same book later, and a sentence you once skimmed may suddenly look like a contour marker that only makes sense after you have crossed that piece of terrain yourself.

09Health, setbacks, and the experiences omitted from success stories

Career plans easily omit the person who has to carry them out. By the mid-thirties, the body offers feedback more directly than a performance system. Sleep loss, inactivity, and sustained pressure do not pause because the project matters.

I used to promise myself I would exercise after the busy period. There was always another busy period. The busier the work becomes, the more deliberately we have to preserve recovery, because clarity, patience, and emotional stability are part of judgment.

A decade at work also leaves us with experiences that rarely make it into polished success stories: team conflict, technical disputes, platform-versus-business tradeoffs, low morale, personal lows, and a decision you defended fiercely before evidence proved it wrong.

Experience creates value only when reviewed. What happened? Which signal did I ignore? What would I notice sooner next time? Through that work, failure slowly becomes judgment. When others need direction, they do not expect you never to have struggled. They expect you to have something more useful than panic when the struggle returns.

10Planning ahead should not mean borrowing anxiety from the future

Some colleagues began practicing the responsibilities they expected at year ten by year seven. They sought difficult projects, learned to lead and communicate, and some even tried entrepreneurship to understand resources and accountability firsthand.

By year ten, those “advanced” capabilities had already been practiced for three years. The difference was not a few more books, but several more complete loops of judgment, action, and feedback. That gap is difficult to close in the months before a promotion review.

Preparation should not turn a career into a suffocating countdown. Its purpose is to reserve space for growth that matters before it becomes urgent: learning to listen before managing, understanding customers before owning a business outcome, and caring for health before the body forces the issue.

Part V · Return to the measure of a year

11If promotion is not the measure, what did the year leave behind?

So how should a programmer measure a year?

My 2018 answer did not deny the practical meaning of level and compensation. They shape opportunity and life. But if the year is reduced to one performance outcome, much of what matters disappears.

At the end of the year, it may be worth taking one quiet afternoon to ask:

• Problems: Can I handle problems that are more complex and more real than a year ago?
• Craft: Is my work more dependable, more maintainable, and built to last?
• Influence: Did anyone do better work because of my explanation, support, or example?
• Judgment: Did a failure change a later decision, or merely become another story?
• Life: Can I continue with health and clarity, without burning myself out?

These questions do not produce a universal score, and they may not all fit into a promotion case. They make growth observable before a distant verdict arrives. When you can see where you are growing and what is still missing, feedback from managers and peers becomes a signal for calibration rather than a final judgment of personal worth.

A year cannot be measured completely by a table. It exists in the difficulties you can finally carry, the detour you help someone avoid, the reliable delivery, the honest correction, and the effort you sustain without exhausting yourself.

Promotion records part of that. The rest is ours to notice.