Reflective Practice
When we are actually coding, we usually are completely alone. I'm currently on a five year project. No one can do as many as a dozen of them in a career. These factors make it hard for us to learn by experience.
Programming isn't the only profession to face this challenge. My wife is a design educator. She encourages her students to keep a "reflective practice journal". Keeping a professional diary helps them to learn more lessons from their experience.
Another thing that helps is pay attention to each other. I like to attend the meetings of other projects. When I have less at stake, it is easier to observe the dynamics at work.
Donald Schon pointed out that professionals do not really have a body established theory which provides answers to all the problems they will be asked to deal with. Rather they improvise on the basis of a repertoire of techniques and experience in using them. This is true even in mature professions like civil engineering. To improve, they must not only learn more theory, they must also think about what they have done. He described this as "reflective practice". See
Schon, Donald. (1983). The reflective practitioner. New York: Basic Books.
His talk "Educating the Reflective Practitioner"
is available at http://educ.queensu.ca/~ar/schon87.htm.
That is what my blog is for. Elsewhere, I have a TO DO list. This blog is my TO THINK ABOUT list.
You can't be "competent" at an undefined task
See my blog if you like, Chris.
Selecting for reflection
My project is a complex one. We are currently in transition. Having finished most of the work on the back end, we can put more resources into responding to user input. It has also become clear that some of the user communications we have had are more "suggestions" than "needs". For these reasons, it is time to raise our game from developing features to designing solutions, to use Dan North's expression.
Team members vary in how well they are responding to this challenge. Some of us, like me, are career programmers, and others have a first training in the application domain. The response is not what I first expected. The programmers understand very well that they need to find out about the domain, whereas the domain experts are focussed on the programming, which for them is the hard part.
The people who are performing least well here are the least reflective. Being very competent at a defined task is not enough in a situation of flux.
This should be a selection criterion. So my question is, how do I identify the more reflective candidates, who will grow as the project mutates?