How To Be a Great Programming Mentor
A reference for mentors by an experienced mentee
Whether you’re a mentor or a mentee, everyone can and should agree that mentoring in programming is difficult to be good at. Because it can be so hard to identify the problems holding back new learners, teaching tends to be a tiresome job. Luckily, mentorship and teaching have a few very important discrepancies.
Mentorship in Programming Is Hard
In an ever-shifting landscape like the world of software development, it’s extremely hard to pinpoint what information is valuable enough to keep or pass on to others. I’ll elaborate a little bit on why the approach is a little more complicated than just showing them how to do things.
Programmers are opinionated
Every programmer, whether they know it or not, has strong opinions. Here are just a few examples of the infinitely numerous and pointless battles that developers fight on a near-daily basis. Not that it matters, but I’ve included my own opinions in bold:
- Two-Space Tabs vs. Four-Space Tabs (Two-space Tabs)
- Hard Tabs vs. Soft Tabs (Soft Tabs)
- Perfectly-Fine Language vs. Other Perfectly-Fine Language (The first one)
- Git Rebase vs. Git Merge (Git Merge)
- Vim vs. Emacs (Emacs, but I still use Vim)
Basically, if a side can be taken, programmers will take one. This makes it hard to be objective when showing the ropes to a newer developer.
New developers are impressionable
The typical image of a programmer that people envision is that of someone with infallible knowledge about the digital universe. One of the first questions I usually get when people find out I’m a developer is, “So, do you know how to hack stuff?”
Although not every new programmer has dreams of hacking the Pentagon, they all have an idea of what kind of programmer they want to become. Usually, it’s a game developer. These ideas will urge people to take shortcuts and take the shortest path to their endgame.
So, What’s the Mentor’s Job?
Here’s my best shot at a succinct description,
A mentor’s job is not to teach material and inform. It’s simply to show new developers how to learn, encourage good habits, and act as a supportive peer.
Showing new developers how to learn
This is something that requires a strong sense of empathy which, of course, programmers are not typically known for having. That being said, all you need to do is remember what it was like to struggle with every new concept that was thrown at you. To new devs, things don’t just make sense. Learning a programming language is like… well, learning a new language. Rules that you know by heart and consider obvious are completely foreign to a newcomer.
Unfortunately, you can’t learn for them. Until some technology is invented that can transfer knowledge from one to another, you’ll have to figure out how they learn. Many programming concepts are objectively hard to grasp. At the end of the day, it’s up to the learner to figure them out. Explanations can be thrown left and right, but what you should be searching for is that thing that makes it click.
Encouraging good habits
Sounds a little bit cliché, I know. Even so, I can’t count the number of times that I’ve said and been told, “Just forget about documentation.” It’s funny to mock habits like documentation and good variable/method names when you’ve gained enough experience to know when it’s wrong. To a new dev, though, a phrase like, “Documentation is stupid,” is not understood as a joke. It’s understood as a lesson.
Mentorship is an opportunity to get these good habits right from the get-go. Even if you don’t personally follow a lot of them (though you should), it’s important to help learners develop these habits early. Here are a few good habits that I wish were pushed on me when I was first learning to code:
- Document your code (meaningfully)
- Spend more time planning/thinking and less time coding
- Be consistent in how you write code. Don’t have a variable named
badAppleand another named
- If you have a question, formulate a precise question. Rather than saying “It doesn’t work,” ask “Why is my method changing the original array rather than creating a copy?” Oftentimes, problems can be solved just by asking the right questions.
Acting as a supportive peer
This tip comes from my frustrated, alienated, past self. A select few of the mentors I’ve had saw themselves as such. At the end of the day, the tech community is made up of an incredible number of supportive peers. You should try to become one of them.
A mentor-mentee relationship is not one with a power dynamic. You are peers. Although you may know exponentially more than the person you’re mentoring, no developer should ever be done learning. Being a student alongside your student is paramount to ensuring that they understand it’s OK to make mistakes. We all make mistakes. The sooner that attitude is adopted, the better.
Conclusion — Be the Mentor You Wish You Had
For those of us lucky enough to have had one or more mentors in our journey to become developers, it’s helpful to compile a list of the most helpful lessons learned from them and add your own. If you’ve never had a mentor (you have all my respect), imagine the sort of person you’d like to have learned alongside and become that person.
If you really want to help new developers, learn alongside them. It really is an incredible experience as a new dev to witness how a seasoned veteran approaches learning something new.
You should be a mentor — not a lecturer. Talking at people is a valid way to teach concepts. That’s how college works, after all. But you’re not a one-person college, and it won’t help anyone learn to adapt and grow.
If you know someone who is trying to learn to be a developer and you’re somewhat-experienced, or at least know something they don’t, then consider becoming a self-proclaimed mentor and join them! I genuinely can’t endorse mentorship enough.