Mentorship in Software Craftsmanship - part 3
Join the DZone community and get the full member experience.
Join For FreeOnce the relationship between mentor and mentee is established, it is
fair to say that they will be in a journey together. Every software
craftsman is on a personal journey towards mastery. They are all walking
the long road. Both mentor and mentees will be learning while they share part of their journey with each other.
What mentors and mentees should do during the mentorship?
Well, this may vary a lot depending of the type of mentorship. In
general, they are expected to write code, loads of code. Ideally they
should build something together, where the mentee should be the most
active in terms of writing the code. The mentor is expected to
pair-program with the mentee whenever possible and to be reviewing his
code.
Agreeing on creating an application would probably be the best option
since that would involve not just writing the code but also thinking
about requirements, being able to prioritize, defining a development
process, deployment strategies, production environment and everything
else that is related to a software project in the real life.
Working on katas is also a valid. It's a simpler and quicker approach
for the mentee to learn basic skills. This could be used when the
mentees are interested in the basics of TDD, naming, refactoring,
programming languages paradigms, etc. However, after learning a few
basic skills using katas, they should aim to do something larger that
really can mimic the sort of applications they would be working on in
their professional environments.
Establishing goals and tracking progress
Establishing goals is definitely a good practice in a mentorship. It
keeps mentor and mentees focused in whatever they want to achieve.
Working towards an objective is always the best way to study and learn
something. Goals should be achievable and used to motivate and direct
the menteed and not to be treated as a hard deadline. However, they
should be as concrete as they can be, for example, writing an
application with features X, Yand Z and have it deployed into production
or doing a number of katas using TDD, write blog posts, read books,
submit patches to open source projects, or whatever the pair agrees on.
It's important that progress is tracked so both mentor and mentees can
see how they are getting on and how much the mentee is evolving.
Tracking progress is all about feedback. The quicker and shorter the
feedback loop is, the better. It's also a good tool to trigger
conversation about improvements and refinements.
How long a mentorship should last?
Unfortunately that's another question that does not have an exact
answer. This will depend a lot on the type of mentorship, how much the
mentee wants to learn from the mentor and also how much the mentor has
to offer.
Some say that this should be a lifetime commitment, some say that it
should last between 2 to 5 years and some say that it could be as short
as a few months. Some mentorships start with very technical and specific
things like learning the basics of a language or test disciplines.
However they can evolve to an entire project lifecycle or even to a
longer term career advice, networking, help with books and conferences,
etc.
I, personally, would never try to define that upfront. Just enjoy the
journey and let time tell when the mentorship should terminate.
How and when does it terminate?
For the majority of the relationships, both mentor and mentees at some
point need to continue their journey in separate ways. This does not
mean that they will never talk to each other again or that they don't
like each other. This just means that they need to move on, teach or
learn from other people. Also, we all change our minds in terms of what
our next steps would be and we need to react to that.
One important thing is that regardless who wants to terminate the
relationship, this termination should be explicit. It should be clear to
both parts that the mentorship is over.
Professionalism, Reputation and Public recognition
Software craftsmanship is all about professionalism and it is almost impossible to talk about professionalism without talking about reputation.
Throughout the mentorship, it is important that the mentor advertises
the progress of her mentee. Mentors should public recognise all the
skills acquired by the mentee, what would help the mentee to start
building her own reputation. However, mentors also need to be aware that
every time they vouch for someone, they are also putting their
reputations on the line. Mentees are also expected to be recognising
their mentors for all the things they've been learning. This mutual
recognition is one of the things that may help both to build their
reputations.
Raising the bar
Mentorship is at the heart of software craftsmanship and this is
probably one of the most efficient ways for us, developers, to help
raising the bar of our industry. Sharing our knowledge and experiences
with each other is what will help us learn from our mistakes and
successes.
We probably can teach many things to someone in a fraction of the time
that took us to learn them. With this, mentees could absorb a lot of
knowledge in a much shorter space of time, making them, overtime, a much
more complete professional than any of the mentors she had in her
career.
Regardless of our level of seniority or if we are being mentored by
someone else, if we all take the responsibility to mentor someone, we
will all be helping to raise the bar of our industry.
For previous parts of this blog post, please check:
Part 1: Mentor and mentee roles, gains and sacrifices, mutual respect
Part 2: How to choose mentors and mentees and mentorship misconceptions
From http://craftedsw.blogspot.com/2011/10/mentorship-in-software-craftsmanship.html
Opinions expressed by DZone contributors are their own.
Comments