Please patronize sponsors of this page!
Bytesmiths no longer is involved in software consulting. Maintenance of this web site is currently subsidised by unrelated business activities. Please pass the word to other interested folks, so I can continue to host this page!
- 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.
- Green Chipper -- light forestry and environmental services.
- Info Ark -- a huge collection of useful information.
- Varalaya Farm -- organic produce and sustainable farming education.
- 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
Your site could be listed here, for as little as $12 per month! Go to Bytesmiths Press for details.
This site has been selected by PC Webopaedia as one of the best on this topic!
This site has been awarded a Links2Go Key Resource Award in the Smalltalk category!
Originally published in The Smalltalk Report, October/November 1996.
by Barbara Yates
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
- 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
This project had one team member who was a very
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
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
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.
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.
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!
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
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
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
"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!
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).
Members , Jan Steinman and Barbara Yates, The
Smalltalk Report , V5N6, February 1996, pp. 15-17, 28.
Go to the previous
column in the series, or the
next column in the