Having (or being) a mentor can be very rewarding for both involved, but it’s still not a practice formally embraced by a large percent of the developer community.
We’re going to investigate what mentorship is, who benefits from it, and the ways you can approach it at your company, or in your personal time.
#What is mentoring? Mentoring is when one person helps another learn, and grow over, a period of time.
A mentor can be a formal relationship, like hiring a senior or architect-level person to help level-up the team. It can also be very informal, such as a friend or acquaintance. In the case of informal mentoring, it‘s often difficult to gauge just how much the mentor is willing and able to help.
It’s not that they don’t want to! Most have full-time jobs, some have families and other commitments. There’s no steadfast rule — after all, some people really enjoy helping others — but generally, keep in mind that informal mentorship doesn’t mean your mentor will help you debug your code every day, or even every week.
Your mentor also isn’t just to help you fix bugs, though that does happen. Generally speaking, your mentor should help guide and inspire you. Sometimes that’s giving career advice, or it might just be fun discussions around the latest hip technologies, and their tradeoffs.
#Who benefits from mentorship? You might not be surprised to hear that everyone, without exception, can benefit from mentoring! Not just the person receiving it, but also the mentor themself! It’s been said: “If you want to learn something well, teach it.”
Of course, engineers who are more junior or mid-level benefit the most from having a mentor. Most of the world’s top engineers had someone who helped them level-up, even if it was just a more senior co-worker.
Still, “senior” doesn’t mean that they have no more room to grow. You can always find a developer with more knowledge in particular topics. Unfortunately, many senior developers end up in a situation at their company where they help mentor the junior developers, but no one mentors them. The senior engineers at the company are all pretty good, but each is not amazing by themselves. In this case, these senior developers should mentor each other, transferring their unique experiences between each other, or they find mentors from outside the company.
The effectiveness of a mentor-mentee relationship comes down to two things primarily: the difference in knowledge and experience between the mentor and mentee, and how good the mentor is at transferring knowledge.
I say “transferring knowledge” instead of “teaching” because the act is much more organic. Mentees don’t just learn facts, they pick up techniques, habits, and opinions from their mentor.
Mentors should ideally have far more experience in a particular domain than their mentee, but this requires some important nuance: two developers can be very experienced in completely different domains, so just because two developers have the same number of years programming, it’s common for them to have non-overlapping experience. They both have a lot to learn from each other.
#Methods of Mentorship Mentorship takes many forms. Which method of mentorship works best varies between pairs of people because everyone has different preferences and styles.
There are four primary ways we see mentorship work:
-Organic discussions -Pair programming -Code reviews -Lunch and learn
Let’s dive into each of these.
#Organic discussions By and large, this is the most common form of mentorship. This happens every day at many companies, where one developer is talking to another, teaching them something new, or sharing their opinion on possible approaches.
In many ways, this is often what a good software architect does. They don’t just provide the architecture as a demand, they present solutions in a dialog. They solicit feedback, explain their recommendations and alternatives. They empower developers to be more self-sufficient and grow. While natural within the normal course of a developer’s job, it can take on a whole new level if it’s specifically adopted as part of the team’s culture. Leadership can start to foster these relationships by embracing it and explicitly stating it as an encouraged use of time.
#Pair programming When pair programming, one developer, the driver, writes code while the other, the observer, reviews the code as it is typed in. This can happen in-person, sitting next to each other, or it can happen remotely. Exactly how this plays out in practice is totally up to you. Sometimes, the observer acts as a sounding board for the driver on request. Other times, they take a much more proactive role in providing feedback in real-time. Pairing can both catch bugs or performance issues before they happen, and make it easier for the team at large to maintain the code later.
In one study, 96% of developers enjoyed their pairing time more than solo, and 95% were more confident in resulting solutions when they paired. But that also means pair programming is not for everyone.
Often, pair programming creates opportunities for organic discussions. You might be working on debugging some async code with your mentor, and then learn how microtasks and scheduling in JavaScript work, completely changing your understanding of async programming.
#Code reviews Instead of committing code directly to a repository, you can adopt a [pull request] (https://medium.com/r/?url=https%3A%2F%2Fhelp.github.com%2Farticles%2Fabout-pull-requests%2F) model, in which the author submits a request to merge their code from one branch into master. This gives other developers an opportunity to review the changes.
Reviewing the changes provides two primary benefits. First, other developers have insight into what is changing and any potential impacts on the work that they’re doing. The pull request model also gives developers an opportunity to catch bugs, suggest more ideal or idiomatic implementations, and generally share knowledge.
Effective code reviews are actionable, but empathetic. It’s very easy to be off-putting in your comments, and make the author feel like you’re talking down to them. But that doesn’t mean you shouldn’t include nitpicks! I would encourage teams, when possible, to discuss their preferred tactics for reviews. Should reviewers include code-style changes and other things that are subjective?
Often it’s helpful to include a signal that a particular piece of feedback is subjective, like: “nit: we might extract this into a method so we can reduce duplication here and here. What do you think?” This signals that the suggestion is optional and requests the author’s opinion.
Having good rapport and trust between the developers is super helpful as well; developers who trust there’s no malice between them are far more likely to be able to have efficient discussions on tradeoffs. Unfortunately, this isn’t always possible — open source projects frequently have contributors who they’ve never met — so empathy and word choice is particularly important.
#Lunch and learn A lunch and learn (or “learn and lunch”) is when a group of developers get together during lunch, and one of them presents a particular topic. The topics are usually technical, but not always! Lunch and learns are not formal mentorship, but they’re a great way to share, and inspire, in a casual setting.
Lunch and learns work best when the company already provides free lunch. They should also be very informal; the presenter doesn’t have any obligation to make slides or come up with a particular outline of discussion. Some presenters will want to do this, however, so it shouldn’t be discouraged.
Although there are no rules, I really recommend letting the team self-organize the topics and schedule, and have all topics be fair game--not just those related to the company. It’s important that the lunch and learn is also completely optional. Also, make sure to never let it turn into a “meeting” where the team feels like they have to use the time to cover current project-related details.
These lunches should serve as an opportunity for individuals to share things they are passionate about, and spark passion in others. At the end of the presentation, the group should include time for discussion, where the team can ask questions and even partake in some friendly debate if applicable.
Of course, if you find people aren’t enjoying lunch and learns, don’t do them! Not every team is composed of developers who are comfortable presenting their passions, and that’s totally okay. The last thing you should want is a team feeling like they have yet another meeting or that they are overly burdened.
#Conclusion Mentorship can provide anyone a very effective way to boost their knowledge, no matter their experience level. Although you can seek out formal mentor relationships, informal ones happen all the time, usually without any labels, and should be embraced as well! Find someone you admire, and ask them for guidance (without taking advantage of their generosity). You might be surprised at how willing people are to help.
This article was written by Jay Phelps who is a Mentor at This Dot.
You can follow them on Twitter at@_jayphelps.
