Mentoring. In the post-modern melange of language that seeks to verbify every noun and leave no word of action without it's nominalization, “to mentor” is a very cool activity indeed. A mentor is, of course, a teacher. But more than just a teacher, a mentor is also a guide and master—part career counselor, part coach, part colleague. In some areas of software development, coaching has become almost as popular as mentoring, even though coaching is a real word and sounds far less sophisticated. Just listen in on the conversation among a group of consultants at a conference and you are likely to hear some announce that they no longer do consulting. Instead, they provide clients with a “mentoring and coaching process.” Indeed!
According to industry pundit Ed Yourdon, mentoring has become a hallmark of the Microsoft culture and the cornerstone of its approach to improving software. New hires are assigned a mentor who reviews every line of their code. And the “mentee” (but, of course!) reads every line of code the mentor writes. Here, we are told, is living evidence of a commitment to quality and improved processes at the great ranch at Redmond.
Having come neither to praise nor to bury Caesar, I'll stay out of the ever-popular deconstruction of Microsoft and instead turn to a closer look at what mentoring is and is not. First, it is not new. Despite its neologistic cloak as part of the total quality and process improvement movement, mentoring is old stuff. Mentoring is the master-apprentice model without the sting of indentured servitude. It is a dressed up version of what old-timers knew as the “Sit-by-Nellie” approach to software engineering. Ed Yourdon and I even wrote about this humble technique in the first edition of Structured Design (Yourdon and Constantine 1974). The new programmer is told, “Sit by Nellie. She knows how to program.” It was, as we explained then, a symptom of a problem. Since no one knew exactly what Nellie did that made her so good, and even Nellie herself could not exactly put it into words, the best way to learn was to sit beside her and watch her code.
Apprenticeship is a better training model for the craft of programming than for the discipline of software engineering. A discipline requires that there be people who can do it, that there be people who know what it is that those who can are doing when they do it, and people who know how to teach others how to do just what it is that those who can do it are doing when they do it well. Mentoring is what you do when you either do not understand what you do or cannot cast it in a form that can be readily and reliably taught.
Naturally, the doers, the thinkers, and the teachers in software are not always the same people. Some of the best developers in our business, even some of our grand gurus, may have only vague or misguided notions of what it takes in order to do what they do. On the other hand, the best teachers may be only mediocre programmers. Teaching and programming are quite different skills.
Nellie is by now a great-grandmother, and the only programming she probably attempts is trying to get all four parts of the latest PBS special recorded on her VCR. However, the computer field still abounds with programmers and designers who do their work well but could not explain it if their jobs depended on it. And the nearer you are to the frontier, the leading edge of practice, the more this seems to be true. At one conference in Sydney, Australia, devoted to object-oriented development, mentoring was mentioned at every turn. It was promoted in presentations and in comments from the floor as the golden route to proficiency in object technology. Perhaps it is no accident that mentoring is hottest where the technology is newest and the safe ground least clear. Theory, technique, and tools lag the furthest behind the problems and practices in areas of leading edge technology. Where there be dragons, good mentors are needed.
I was mentored by some of the best. Amazingly, there were intelligent coaches brave enough and willing to take on the training of such a troublesome young man. The effects last. I am still sussing out new twists on some of the things I learned first under Jack Cremeans, Ken Mackenzie, Dave Jasper, and Bud Vitoff.
To the extent that it works at all—and it does not always—mentoring will not directly improve quality, however. It only promulgates the style and practices of the mentor. As an organizational strategy, it can be an effective way of promoting the corporate way, assuring that, for better or not, people think and code in channels consistent with the preferred culture.
This consistency in itself may represent a first small step toward a better software development process. Consistency is the grandfather of quality. It is an axiom of process improvement that before you can improve a process, you have to get it under control—it must be reproducible. As long as the process of software development is chaotic, as long as effort cannot be predicted and you never know whether or how deadlines will be met, there can be no systematic refinement or incremental enhancements. The reliability of the end product remains mostly in the hands of Fate or of legions of beta and gamma testers. The first rung on the ladder of quality that leads toward the lofty heights of level 5 in the Software Engineering Institute's Capability Maturity Model (or to software that works, whichever comes first) is reducing the variance, producing more consistent outcomes by more predictable processes. This means, of course, that both the splendid but unexplained successes and the unplanned failures will be lopped off the ends of the distribution, leaving a more stable but less spectacular medium happily in the middle.
If it fits the organizational culture, investing in a recognized and systematic program of mentoring is better than trusting to the natural instincts of spontaneous coaches. In principle, everyone needs a mentor, and everyone should have a go at being a mentor in turn. The mentoring process does not have to stop simply because you passed your first annual review without a hitch. Mentors can help you up the next rung as well as up the first. Mentoring can serve as part of an effective technology-diffusion strategy whenever new techniques and languages are introduced. Coaching can complement both code reviews and design walk-throughs in an on-going quality improvement program.
Mentoring is especially popular among consulting firms who tout it as an effective means of technology transfer. Instead of consulting to your company, they will work side-by-side with you on your project, gently guiding and helping you to acquire their advanced levels of skills. Compared to intensive, up-front staff training or intermittent consultation as problems arise, the mentoring model has obvious advantages, not the least of which being that it offers the consultant more dependable income.
So, at least for awhile, mentoring is the word. The language, though, keeps morphing before our eyes. Language must keep moving and changing lest we catch up with it, or worse, we end up being caught in the act. Smart consultants are merely being wise in renaming what they do. Money for consulting and training may have been squeezed from budgets, but the bean counters and pencil pushers have not all yet discovered coaching and mentoring. Once they do, there will be fiscal limits on coaching contracts, and mentoring will be found petrified in 13 pages of contractual obligation, indemnification, and nondisclosure.
Perhaps it was meant to be!
From Software Development, Volume 3, #3, March 1995.