Some Lessons Learned On Mentoring

Mentoring is one of my favorite activities. No reasonably complex system can be built by a single developer. It takes a team. Helping other members of the team reduces my own workload in the long run, even if it increases it in the short term. Eventually, I found myself enjoying the activity for the sake of it and not just to reduce my own workload. I started treating it as a skill on its own that needed to be improved. Here are some of the lessons I’ve learned the hard way.

The most common advice I hear about mentoring is to avoid giving someone the answer. It would be better if the mentee figured it out on their own. The mentor should ask questions such as “what comes first to your mind? and “how would you approach the problem?”, until they figure it out. It makes a lot of sense because it forces the mentee to think through the problems instead of using someone else as crutch.

I can summarize the biggest problem with this strategy with one question: what do you do if your web application starts crashing and nothing is in the logs?

Most experienced developers will have some kind of answer, but that is because they have a strong foundation of knowledge on how to tackle this problem.

For someone who doesn’t have have that foundation, things get harder. Someone who doesn’t know about replication delay is not going to simply figure out that it is happening. The symptom will be specific to their application so searching for it won’t help. You can’t get the solution for replication delay if you don’t know you should be typing “replication delay into Google.

What’s worse is that the common mentoring questions are only going to frustrate the mentee. One can only answer “What comes to mind? with “nothing so many times before losing their mind. The question “What comes to mind? is meant to force a mentee to connect the dots.

But without a strong foundation of knowledge, the question asks a mentee to connect the dots… when there are no dots.

A mentor needs to recognize when there are no dots. This is where asking questions turns into providing explanations. Giving the answer is acceptable here so long as the answer comes with some foundational knowledge so that the mentee can solve the problem on their own next time.

Providing foundational knowledge also provides the answer to “why” things happen and “why” some things are important. “Why should I care?” is one of the most important questions that a mentee needs answered for them. It’s hard to be motivated when you don’t know why you need to do something.

Answering “why” is even more important when trying to put in place practices that are preventative. It’s easy for someone to understand what is causing a problem. It gets much more difficult for someone to understand the importance of preventing a problem without having first experienced it.

There’s this great article on why experts make bad teachers. An expert is someone who has learned many lessons the hard way. They have experienced issues first hand. Those experiences will get grouped up into abstract concepts. For an expert, these abstract concepts save time. They assume that this time savings will transfer to a novice if the abstractions are taught first.

They are wrong.

Learning something the hard way is not a waste of time. It provides essential context necessary to understand abstract concepts. An example is creating maintainable code. It is incredibly difficult to understand what makes code maintainable without first experiencing multiple instances of un-maintainable code. Those experiences provide context for what is truly maintainable. Without those experiences, programmers write code that they think is maintainable, but is often convoluted.

People need multiple experiences to serve as an example and only then should they be introduced to the idea that those examples all tie together into an abstract concept. These experiences also have the benefit of providing an inherent explanation of “why something is important. The mentor at this point doesn’t need to spend as much effort explaining “why something is important. The mentee will see from their experiences and intuitively start to understand “why on their own.

Not all experiences are worthwhile though. That is the challenge for mentors: how to determine when an experience will be valuable and when it will actually be a waste of time. This is where being an expert comes in because not all of an expert’s experiences would have been valuable either. An expert can use that to differentiate and filter experiences for mentees so that they have experiences that provide the most value.

That includes letting people fail.

A common saying is to set people up for success. In many cases this is true. You want a mentee to develop confidence. You want them to have wins so that they can learn to love the craft you are teaching.

There’s another common saying though. We learn from mistakes. We learn a lot from mistakes actually. Personally, I know I’ve learned a lot more from my mistakes than my successes. My successes have mostly been validation from applying the lessons I’ve learned from my mistakes. Trying to ensure that a mentee will only see success is to deny them great learning opportunities. It makes them weaker in the long run. The confidence they develop will be false confidence.

That’s not to say set people up to fail. But people do need to try to do things on their own. I once had a situation where one person on my team was assigned to work on a feature, but he needed help with software design. I decided to be a knucklehead and designed the whole system for him.

Guess how that turned out?

He came to me for help constantly. Since the design was mine, I had all the context. I had all the intuition on how to fill in all the minor details that don’t get covered in a high level design. That also meant that anytime there was a decision that needed to be made, I had to make it. He was essentially my typist, not a software developer.

This wasn’t right. It frustrated him because he wasn’t empowered and he didn’t learn anything. It frustrated me because it took almost as much time as if I had just built the feature myself.

I learned from that mistake. On a high pressure project, I decided that even though the entire team was working together, it was important that my team gained some experience data modeling on their own. Despite the time crunch, it was worthwhile to let one of the other developers make the data model. I also made a data model for the system in parallel. It sounds like duplicated work, but I wanted to see what the other developer came up with and in the worst case scenario I wanted to have a backup plan.

Guess how that turned out?

Our data models were nearly identical. It turned out that I caught one thing he had missed and he caught one thing I had missed. More importantly, he had the opportunity to put his skills into practice. If we had created the data model together, he would have most likely taken a passive role and let me do most of the speaking. We would have missed an issue that I didn’t account for with my data model.

This paid off exponentially over the next few months. Not only was this developer more effective in his own work, but he started taking a leadership role with the rest of the team. This offloaded a lot of work from me and also ensured that I wasn’t a bottleneck for my team when it came to answering questions or making decisions.

So this scenario ended up working out really well, but I didn’t know that at first. To be honest I actually didn’t put the odds of it working out as that great. I took the chance anyway. In the worst case scenario, that developer would have learned something by practicing and getting feedback. In the best case scenario, I the mentor learned something.

That brings up the next point. Just because you are the mentor does not mean you have to be right all the time. You’re a mentor because you have valuable experience that you can teach. You are not a mentor because you are an omnipotent all knowing being.

This may seem obvious and logical, but emotions are not logical. Being pointed out that you’re wrong by a mentee, especially if that mentee is say… an intern, is going to spring up a lot of emotions. This can happen even if the discussion is about something small.

I once made the mistake of getting defensive and ultimately convincing an intern to see things my way. It made us both weaker because I was wrong. I learned that it isn’t a point of embarassment when a mentee wins a debate with me. It is a point of pride. That is how a mentor knows they are doing their job well. A mentor’s job isn’t to be superior. A mentor’s job is to make someone else better.

That leads into my final point: you are the problem. Always.

That’s not always true actually. The point is to have an attitude where it is. Blaming a mentee for not being smart enough is easy. Too easy. The first time you make that decision, it makes it easier to make that decision again. And again. And again. It makes a mentor complacent. More importantly it also implies there is nothing the mentor can do.

By going into a situation assuming the problem is with you, you acknowledge that you have the power to improve things. This attitude can spark moments of creativity and allow you to come up with solutions that you never would have if you had given up on a mentee too early. Even if it doesn’t work on a particular mentee, and you’ll hit a situation where it won’t, you now have another tool that you can use in the future. That’ll make you a better mentor for others.

Do you have other tips? I would love to hear from you.

This post was originally published on blog.professorbeekums.com