In fifty years we have learned many things about creating software. Where we must now improve is not so much in learning things, but more in teaching what we learned. A university course may teach some basics, but the fact is, it takes several decades to truly learn software development. Most of this learning will happen on the job. Yet we have no widely recognized effective model to organize this learning. Pick any catalog of "training courses" and you will see vendor-specific instruction, not education in the basics of the craft.

The idea of "software craftsmanship" directly addresses this situation. The term "craftsmanship" primarily evokes attention to quality, individual responsibility, pride in one's work. It is certainly suitable as a guide to rethinking a profession that has elements of both science and art. It was also associated once with a formalized and effective system for ongoing training: the guild systems and their divisions of apprentice, journeyman, and master. Are these models still relevant ? At any rate, they offer a different perspective on the situation of the software profession, a possibly valuable source of new ideas.

This talk will start as an experience report: having been part of an experiment in reviving the "compagnonnage" guild systems, I will report from the inside on what these models have to offer, and offer in the following discussion to compare them with other initiatives which hold promise for our profession.