As a software engineer moves throughout their career, they take on more responsibilities. Some of these responsibilities are mentoring junior developers and assisting others that may be having problems. Mentoring is thrown around in many conversations when dealing with senior level professionals. It is assumed that people know what to do when it is mentioned. I am not going to assume that here, so let’s take a look at the dictionary definition for mentor:

  • a wise and trusted counselor or teacher

So, as a mentor, you are expected to be a counselor and teacher of people that may be your junior. As a software engineer, what should a counselor or teacher be expected to actually do? Let’s look at some examples:

  • teach what the expected coding and documentation standards are for your organization
  • assist with debugging issues and testing techniques
  • explain why a certain design or data structure is appropriate (or not) in specific situations
  • help determine what issues could lurk within high-level designs

Much of this really looks like teaching someone the things that they would not learn in schools. Some things are better learned through experience, so it is still appropriate and not someone’s failings. As you can see from the list, much of this mentoring work is also in the form of assistance. So, there is obviously some overlap in terms of the actual day-to-day activities. Anyone can complete a list of tasks like this, but what makes someone a good mentor? This is really a matter of style and not a list of steps. I have seen three different types of mentoring styles in my career so far:

  • Mentors who tell you the answer and explain why the answer is a good one.
  • Mentors who tell you how to find or discover the answer.
  • Mentors who only ask “leading” or “probing” questions to get you thinking in the right direction.

I will not say that any specific type is better than another, but I will say that you need to be good at one of these. Finding which style you are good at will probably take some time, but good mentors are extremely valuable and you should take the time to figure it out.

A mentor that wants to explain the answer really needs to be a good teacher in the same manner as formal education. If you are not a good teacher, I would try to use one of the other styles of mentoring. You can learn to be a good teacher, but that is a much harder process than just trying a different style. This can be a very difficult path as people learn things differently, so your method of teaching one person may not be as effective for a second person. Disappointingly, this style is normally “half done”, where the mentor just tells the other person the answer and does no teaching or explaining.

A mentor that tells you how to find the answer needs to enjoy the learning process. In many cases, the person being mentored may find things in a different manner than the mentor. The mentor can learn as much as the person being mentored in some cases.

A mentor that only asks leading or probing questions needs to be capable of being questioned. For every question the mentor asks, the person being mentored could have several questions that need to be answered. There could even be many “why would that be a good solution” questions that almost feel like someone questioning the mentor’s experience. I have seen this process work in unexpected ways as well, where all of the questioning leads to a better answer than the mentor originally thought about. This is due to the fact that both people are asking various questions and are actively involved in the learning process.

Lastly, environment can play a big role in the mentoring process. Some corporate environments are better suited to just telling junior people what is a good idea, while other environments thrive on people asking questions. So, if you are becoming the mentor, find your style and make sure people are learning from you. You will be surprised what you learn along the way.

Reblog this post [with Zemanta]