Red Squirrel Reflections Dave Hoover explores the psychology of software development

[Previous entry: "More McConnell"] [Main Index] [Next entry: "Ignition"]

Learning as a Skill
Wednesday, December 10, 2003

One of the most enjoyable aspects of the software development lifecycle, in my opinion, is the myriad learning experiences that it provides. In the three years that I have been developing software, this aspect has actually become something of an addiction. I have found this passion for learning to be invaluable as I face increasingly demanding projects and responsibilities.

In the Cutter Consortium's Agile Project Management Advisory Service Executive Report (Vol. 3, No. 6), the Pragmatic Programmers lament,

"Learning is one of the key activities of software development and has a huge impact on the overall project, yet it's rarely taught as a skill to software developers." (page 9)

Now that is an idea that demands attention: Software development teams should explicitly value learning and set aside time not only to learn, but to grow their learning skills. With learning, rather than knowing, as a core value, team members are given implicit permission to ask for help, to admit that they are not experts, and to take time to research. Unless the team is encouraged to learn throughout the development lifecycle, they are doomed to repeat the mistakes that all of us inevitably make.

"A typical software project can present more opportunities to learn from mistakes than some people get in a lifetime." --Rapid Development, p. 29, Steve McConnell

Replies: 1 Comment

Encouragement is good, but nobody follows the idea through to its conclusions. If people are to learn, they need time to experiment on things and do not necessarily have anything to show for it. If you fail to do something, you have learned. But there is no actual deliverable management can get their hands on. Thus learning is forgotten or purposely not done as soon as the schedule gets even a little tight!

The way I got around this was to have a weekly 1-hour meeting with the whole team, where each developer would have to present *something* that they learned. It could even be something that they learned *not* to do, i.e. a failure still counts! Asking everyone to present, with peer pressure by not having anything at the meeting, was pretty effective. Of course, as soon as management caught on when time was running short, they tried to get me to quit doing these "roundtables" as I called them. I basically ignored them. :)

Posted by Darrell on 12/10/2003

Powered by Greymatter