Anyone who is reasonably competent will find themselves being pushed up the promotion ladder over the years. Sooner or later you end up wearing the senior developer hat in a corporate team or open source project. If you do not take steps to prepare yourself for that elevation, you may suddenly find yourself a victim of the Peter Principle, where you are promoted to your “level of incompetence.”

As the number of years and projects you have under your belt increases, you find yourself awaiting the epiphany that will magically make you “experienced.”

Become a reflective practitioner of software development. This involves regular introspection into how you are working. Consider whether your practices are novel, innovative, or outdated. Ask yourself questions about the things that the rest of your team takes for granted. If there is something particularly painful or pleasant about your current work, ask yourself how it got that way, and if things are negative, how can they be improved? The goal is to extract the maximum amount of educational value from every experience by taking it apart and putting it back together in new and interesting ways.

One technique that’s useful in making this kind of reflection explicit is to use something like a Personal Practices Map. This is an idea that Joe Walnes introduced at London’s Extreme Tuesday Club. It involves people consciously writing down the things they do and the connections between them. After everybody has written down their practices, the group discusses the practices that have been identified. If you take a look at the web page “Maps of People’s Personal Practices,” ^[32] you will see maps created by Ade and several other developers.

One of the consequences of repeatedly using this technique is that it highlights the changes in your set of practices. So for example, in the years since 2003, Ade has moved from “never using debuggers” to practicing “test-driven debugging” to starting to deliberately use invariants when implementing complex algorithms. The existence of a tangible and visible map of your practices leads to deeper reflection about the effect of any one change in the techniques you use. In Ade’s case, the adoption of test-driven development led to the reevaluation of all the other practices, and the map became a tool for visualizing this change.

This process of observation, reflection, and change isn’t limited to just your own activities. Unobtrusively watch the journeymen and master craftsmen on your team. Reflect on the practices, processes, and techniques they use to see if they can be connected to other parts of your experience. Even as an apprentice, you can discover novel ideas simply by closely observing more experienced craftsmen as they go about their work.

In 2004, Dave was part of an XP team that contained several world-class developers. They had a fairly standard style of pair programming: one guy would write a test and slid the keyboard over to his pair, and his pair would make the test pass, immediately write a test, and slide the keyboard back to the first guy. The first guy would pass the test and so on. This style of pair programming was never really discussed; it just emerged out of their respective experiences.

Dave joined his next project, and while explaining this style of pair programming to his new teammates he realized that the style needed a name. Dave blogged about it, which kicked off a chain reaction that quickly led to an offer to write a few columns for StickyMinds.com. All this happened simply because Dave reflected on the practices introduced by more senior developers.

The Agile community has adopted a version of this process. Driven by Norm Kerth’s book Project Retrospectives, it involves the team periodically gathering to look back on the state of the project in order to find ways to improve. As such, it is more formal than the continual self-analysis that an apprentice will undertake. It also requires reasonably enlightened management willing to provide a safe environment by honoring Kerth’s prime directive: “Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.”^[33]

Apprentices won’t always have the luxury of working in such environments, but the habit of productive reflection can be useful even in less forgiving corporate cultures.

If you hang on long enough, people will start calling you “experienced,” but that should not be your goal. All experience indicates is that you have been able to survive. It does not indicate the amount you have learned, only the time you have spent. In certain parts of our industry, it is quite easy to repeat the same year of experience 10 times without making significant progress in your abilities. In fact, this sometimes can turn into anti-experience: the phenomenon where every additional year or experience merely reinforces the bad habits you have picked up.^[34] This is why your goal should be to become skilled rather than experienced. The increase in your skill level is the only meaningful testament to the effort you have spent inspecting, adapting, and improving your working habits.

Draw a Personal Practices Map for your working habits. Concentrate on the connections between any practices that have not changed in a while. Ask yourself how your map would change if you discovered that one of those practices was actually counterproductive. Closely examine one of those practices and find out if there are other ways to achieve the same goal. These don’t have to be better ways; it’s enough for them to be different. Now ask yourself what would happen to your map if you were to adopt one of these different practices.