Mentoring in Software Craftsmanship - part 2
by
Join the DZone community and get the full member experience.
Join For Free
In part one I
gave a bit of background history and also described the roles and
responsibilities of mentors and mentees according to the Software
Craftsmanship principles. In this second post I'll be convering a few
other areas related to the relationship itself. Remember that the focus
here is on mentorships outside work. Let's start from the beginning.
How do we find mentors or mentees?
That's probably the most difficult question to answer. I can think in three possibilities (in no particular order):
- Try to find someone that works with you in a daily basis. It will make the approach easier.
- Via user groups and communities. If you are an active member of a user group or community you will have the opportunity to meet a lot of people and maybe find the mentor or mentee you are looking for.
- Via indication: A friend could recommend/introduce you to someone.
Although not a rule, normally, in Software Craftsmanship, it is the
mentee that chooses the mentor or, at least, start the conversation. The
mentee needs to have an idea of the path he wants to take. For example,
he may want to learn more about mobile development, work as a
consultant, work in high-performance low-latency systems, learn about
gaming development, improve his automated testing techniques or, in the
best case, just learn how to become a better developer. Whatever the
mentee's ambitions are, the mentee needs to make sure that his future
mentor is a person that can provide the knowledge he or she is looking
for.
Unfortunately, this may be easier said than done. Depending where the
mentee is in his career, he may not know exactly what he wants. He may
not even know what options he has. Although good developers are good
developers and the foundation and priciples of software development
always apply, we all know that the skills set used in different types of
systems can vary a lot. A well experienced developer that spent the
majority of his career doing web-development and became an expert in
user experience may take a while to perform well in a completely
server-side, asynchronous application with no GUI. Working on an
application that heavily rely on algorithms and that don't use any
database can be totally different from developing a mobile client
application. The same way that working for a consultancy company can be
very different from working for a bank or a startup.
Those are some of the things that developers at early stages of their
careers may not even have a clue. If you are at this stage in your
career, the best suggestion is that you focus purely on being a great
developer and learn the basics. Things like Test-Driven Development,
clean code, refactoring, Object-Oriented principles, different languages
and paradigms. Once you have that, it will be easier for you to choose
your next move.
Choosing a mentor involves is not an easy task. Maybe a single mentor
won't be able to teach everything a mentee wants to know. Mentees should
focus on their very next step(s) instead of focusing in everything they
want to learn throughout their entire career. Mentees may change their
minds quite often as soon as new opportunities and options are presented
to them. They should keep their options open and choose a different
mentors as time goes by.
Choosing a mentee
Mentors, before accepting a mentee, should ask themselves: Would I be
able to dedicate time to this person? Can I really help his or her
career? If the answer is yes, fantastic.
The first thing to look for in a mentee is passion. Since a
mentor will be allocating time to help someone, they should make sure
that this person deserves their help. Make sure that the mentee is
committed to be better.
Another thing mentors need to decide is what sort of seniority level
their future mentee should have. Some mentors will prefer to take
graduates, others prefer juniors with one or two years of experience and
others prefer to get seniors or mentees on the verge of becoming
seniors.
Choosing a mentee is a very personal thing and different mentors will
have completely different criteria. If the mentor already knows the
mentee, than it is easier. When the mentor doesn't know the mentee I
could suggest a few options that could either be combined or used
independently:
- Introduction letter: The mentor could ask the mentee for a summary of his career so far (not a CV). In this summary, the mentee would describe what he has done, where he thinks he are in his career, the things he learnt, provide (if any) links to his public profile like github account, twitter, blog, web/mobile applications and most importantly, what he expect from the mentor.
- Coding challenge: The mentor can set up a challenge before considering to speak and accept a mentee. E.g. the mentee, using his preferred language, needs to write a simple blog or wiki application, have it deployed in somewhere (heroku, cloudbees, Google App Engine, Amazon Beanstalk, etc) and code should be public (github, for example). Or it could be simpler like solving a few katas using two different languages or anything along these lines.
- Blog: Mentee should create a blog, if he or she does not have one, and publish a few posts related to things he has been learning on his own.
The mentor, if going down this route, should set the challenges
according to the level of seniority he is expecting from the
mentee. Once the mentor is satisfied with the initial effort by the
potential mentee, he could decide if he is going to accept or not the
mentee.
Mentorship common misconceptions
The mentor is not better than the mentee.
In general the mentor will have more knowledge and experience in the
areas where the mentee has chosen to be mentored. However, the mentee
can easily have more knowledge than the mentor in other areas. Mentees
should not expect the mentor to have all the answers to all the problems
and mentors should not be naive to think that the mentee doesn't know
anything. Both mentors and mentees have skills and limitations and this
needs to be understood by both parts.
Mentors should not be looking for themselves a few years younger. This
can be frustrating for the mentor. People are different and the mentor
will be missing out when not being more open to the type of mentee he or
she is prepared to take on board. There is no reason to be so
restrictive. Mentoring someone with different personality, possibly
slightly different ambitions can be extremelly enriching for both
mentors and mentees. However it is important that both have same values
and principles.
Mentees should not expect that mentors will change their lives. The
mentors will be there for the mentees, giving them advices and teaching
what they know but it is up to the mentee to decide what to do with it.
Mentees should do their part to improve and not think they are going to
be spoon-fed by mentors. It's up to the mentee to look after his or her
own career.
In the next posts I'll be covering things like different types of
mentorship, activities that could be performed by mentors and mentees,
public recognition, professional reputation, graduation, mentorship
duration, how this could change our industry and a few other points.
Watch this space.
From http://craftedsw.blogspot.com/2011/10/mentoring-in-software-craftsmanship_09.html
Software development
Software craftsmanship
Opinions expressed by DZone contributors are their own.
Comments