• Bytesmiths Editions -- large, archival, fine-art photography on unusual materials
• Bytesmiths Press -- artists' services: web design/hosting, jury slides, giclee reproductions, opening announcements, brochures, etc.
• Champagne Beadworks -- handcrafted jewelry and beadwork
• Crafted By Carol -- handcrafted jewelry and beadwork
• Dharm Atma Yoga -- Kundalini yoga instruction
• EcoReality, an organization devoted to establishing a sustainable ecovillage
• Ecovillage Newsletter -- Diana Leafe Christian's news of her travels.
• Environmental Education Outreach -- providing environmental education worldwide.
• Gemini Gypsy -- Carole Good-Hanson's fused glass frames
• Green Chipper -- light forestry and environmental services.
• Salt Spring Island Society for Community Education -- community education on our island of 10,000.
• Veggie Van Gogh -- two artists' mobile warehouse and living quarters, petroleum-free!
• Veggiemog -- life and times of Kelly O'Toole's Unimog, running on biodiesel

Does anyone else out there think the word mentor is overused and abused in our industry? We are often dismayed at the ads we see from companies trying to recruit Smalltalk "mentors." It seems that anyone with a year or more of Smalltalk experience is deemed capable of mentoring, judging by some of the ads. We want to tell you it just ain't so!

What a Mentor Does

A dictionary definition of a mentor is "a wise counsellor (one who advises and warns)."1 A good mentor gets great personal satisfaction from helping others to learn and grow. They can be compared to a good teacher. They are not a Smalltalk guru who takes over your keyboard and writes your code for you. A mentor needs patience and excellent communication skills, in addition to knowing the technical content of the subject in which they are mentoring. Mentoring is a one-on-one activity, so it is important that there be a "personality click" for the mentoring to be successful.

When a manager wants to recruit one or more mentors for their team, it's important that they check references. When talking to a manager of a team the mentor has worked with, it would be useful to ask to speak with some of the team members about their experiences. Given the time crunch most managers are in, there might be little time for checking references. At a minimum, here are some questions the candidate-mentor should be asked:

• How would you handle a team member who doesn't want to ask for your help?
• How would you deal with a team member who asks very low-level questions most of the time?
• What aspect of mentoring do you like most?
• What percentage of your time would you expect to spend programming in Smalltalk vs. mentoring?
• What is the hardest problem you've had to deal with as a mentor and how did you solve it?

Mentoring is a lot more difficult (and sometimes a lot less fun, to be honest) than programming in Smalltalk. Every mentor can probably tell a few horror stories about their experiences. We'll briefly share a couple with you.

We were called upon to mentor a small team of novice Smalltalkers. We were not supposed to be mentoring full-time, but also had major architecture and development responsibilities. We find that the proportion of mentoring to other tasks will vary in different stages of the project, so that when people are deeply into coding, our mentoring will only be about 30% of our work load. More mentoring happens at the early stages, and then it gradually tapers off, as it should.

This project had one team member who was a very smooth manipulator. This person would ask for help with a given problem and a few hours later we would find ourselves sitting at the keyboard writing their code! This keyboard switchover took place without our intention. Regardless of the mentoree's hypnotic abilities, it was our responsibility to help them to learn, not to do the coding for them.

This is where the patience comes in. Of course the mentor can do it faster (maybe 10 or 20 times faster!), but that's not why the project needs a mentor. If the project had wanted you to just crank out code they wouldn't have given you a mentoring role.

The second horror story points out the importance of communication skills and being able to read people. In the course of a six-week iterative cycle on another project, one of us was working with a subset of the whole team on a special prototype. One member of the prototyping group didn't seem to be able to deal with abstraction at all. They repeatedly asked extremely low-level questions that had the mentor stumped about why they were diving so deep. The prototyping group had a tight schedule and a lot to accomplish. The low-level questions didn't need immediate and exhaustive answers because, well, this is Smalltalk and we trust that the longstanding base classes do what they are supposed to do.

The mentor's response to many of these questions was, "Don't worry about that right now. You don't need to know that level of detail." It wasn't until several weeks later that the mentor found out the team member interpreted those answers as condescending, which totally turned off the team member. Unfortunately, the mentor wasn't told how they felt, and the mentor had no clue there was now a problem caused by those answers.

The resolution to this situation happened because a third person on the team talked to both the mentor and the mentoree about how the prototyping project had gone, and discovered the communication impasse. So for the mentors out there (and the mentor wanna-bees!), be careful about the way you phrase things and pay close attention to the reactions of your mentorees.

Epilog: that mentor-mentoree relationship was corrected and became productive again after the mentor was told of the problem.

It is crucial in a project that has mentors that there be a regular mechanism for mentorees to be told of their progress and for mentors to be told of their progress. In a previous column we touched on the subject of end-of-cycle reviews. If the team is doing some reflection about what went well and what needs improvement at the end of each iteration, then telling the mentors how they are doing should be incorporated into this process. If necessary, make this feedback anonymous to encourage people to be honest in their comments.

Mentorees

Just because a manager has recruited one or more mentors for their team doesn't mean they will be well-utilized. The old expression that "you can lead a horse to water but you can't make him drink" seems to be applicable to mentoring. No matter who the mentor is and how terrific they might be in that role, some people just won't drink! There are probably various reasons for that, and it is not something the manager can mandate. It might be helpful for managers and would-be mentors to know that team members typically fall into one of three categories when it comes to mentoring: eager, neutral, and (dare we say it) hostile or suspicious.

Mentor-Eager

The mentor eager developer doesn't fear looking "dumb." They don't hesitate to ask questions. They are concerned about proper OO design and want to learn how to do things "right." This sort of team member asks the mentor for reading suggestions, they explore the class library, and they don't want the mentor to do the work for them. They want review of decisions about design, algorithms, etc. The mentor-eager team member requests design and code reviews. Working with this kind of team member is a pleasure -- it's what gets the mentor through the tough assignments!

Mentor-Neutral

The mentor neutral developer needs to be shown the mentor's value. If there is a good personality match, the neutral developer might become eager. If there's a personality clash, they can become mentor hostile. If personalities are not an issue, this developer might still not make much use of the mentor.

A "neutral" might simply be one of those people who always prefer to figure out things for themselves. Regardless of how good the mentor is, a "leave me alone" developer will not make use of them. There's no point in the manager or mentor forcing the issue.

If a neutral feels comfortable "picking the mentor's brain" on their own terms, then short periods (a couple of hours) of "two-on-a-tube" might be the best way to work with them. This was a technique used by our Smalltalk team at Tektronix in the 1980's. The mentor sits with the mentoree and the mentoree is in control of the keyboard and mouse. They work through a specific problem, making use of the white board and exploring in the image. This short-term, focused activity, aimed at solving a specific problem, is very effective in demonstrating the mentor's value to a neutral.

Some people really enjoy working together closely, and two-on-a-tube periods can sometimes be over a week in duration, depending on the problem to be solved. We recently used this technique for several days in a Smalltalk boot camp we ran, and some people enjoyed it so much they did it for almost the entire two weeks!

Mentor-Hostile

A senior person in non-OO areas who lands back at the beginning of the learning curve with Smalltalk will sometimes reject any attempts at mentoring them. We've found that sometimes they feel so threatened or insecure that they are downright hostile. They are used to being the mentor, not learning from a mentor.

In other cases, team members pay lip service to the value of mentoring, but are in fact disguising the desire to prove they can do it without help. They express this desire as needing "the freedom to make my own mistakes." A sure indication of the mentor-hostile developer is one who challenges all suggestions the mentor makes, and delights in finding and pointing out bugs in the mentor's code (hey, no one is perfect).

As we already said, there is no point in trying to force this developer to accept mentoring. The manager needs to determine whether their insistence on making their own mistakes is hurting the project. If it is, perhaps the person belongs back in a role that makes use of their existing expertise.

Not Getting OO

Organizations that adopt object technology -- Smalltalk in particular -- must realize that their whole team might not learn and progress at the same rate. Some people may never really "get OO." After a reasonable time period (perhaps as long as nine months), the people who still haven't gotten it need to be given alternatives. The mentor cannot be blamed and the developer cannot be blamed. Not all people are able to think abstractly, and they need to be given the chance to contribute to the organization in a job for which they are suited.

Conclusion

"Smalltalk guru" is not equivalent to Smalltalk mentor. Not all team members will accept mentoring. Not all team members will get OO. Do the best you can as a mentor and as a developer, and try to keep egos out of the equation. If personality clashes are a problem, maybe the mentor has to go. This is a tough call that the manager will have to make. Good luck and happy mentoring!

References

1. The Wordsworth Concise English Dictionary . Hertfordshire: Wordsworth Editions Ltd., 1994.

2. Secrets to Building Successful Smalltalk Teams (Tutorial), Bytesmiths at Smalltalk Solutions, March 1996 , New York, NY (CD-ROM soon to be released by SIGS Publications).

3. "Special" Team Members , Jan Steinman and Barbara Yates, The Smalltalk Report , V5N6, February 1996, pp. 15-17, 28.