FwdConf is X-Team's asynchronous conference that ran from the 6th until the 10th of April 2020. This is a recap of its second day, where we interview Josh Johnston, David Roberts, Kasper Myram, and Nikole Garcia, all of whom are X-Teamers with many years of experience mentoring other programmers.
In this interview, we discuss how you can master the discipline and the art of mentoring other programmers. If you want to jump to the other interviews of FwdConf or listen to digestible audio snippets from each interview, click here.
Nikole started the interview by saying that she had a mentor early in her career who helped her with many things. She'd always felt that she wanted to pay it forward and help other people too.
So she set up a local code camp that teaches programmers of all levels, where she realized that it wasn't necessarily the technology that people tend to struggle with. Much can be learned online, after all. It's the cracks between different skills that they struggle with. How can you glue one piece of knowledge to the other?
For example, you can know how to program in a particular language, but how do you make it run on a server? How do you work with a team? How does it all work with version control? How do you set up a project and make it work? Nikole ends up teaching the bridges between knowledge.
Additionally, sometimes, mentoring doesn't have to do anything with tech at all. It's helping someone format their resume, giving someone a high five when they've done something well, etc. Much of it is giving people that little extra push when they need it most.
Kasper said that a good mentor acts like a good leader, with empathy and patience. Nikole added that a mentor needs to be able to unlearn too. After all, your mentees are by definition not at your level, so you need to put yourself in their shoes and understand what they're struggling with.
There's also an element of vulnerability in being a mentor. This is particularly true when a mentee did something wrong (e.g. delete the production server). You can connect with someone who's feeling bad by telling them how you screwed up royally a few years ago. Having that honesty will help your mentees realize that no one's perfect and everyone struggles on the road up.
When it comes to giving feedback on a PR, David said that you can't just say “this is how to do it better.” Instead, you need to explain what the benefit is of doing it a particular way, whether that's a benefit to the codebase, the company, or the individual. If there's no benefit, then it's just a matter of opinion.
Josh said that code reviews are a great way to mentor someone, because you get plenty of small opportunities where you can subtly adjust someone's behavior for the better. It's also a test for the mentor. If you can't clearly explain something small to your mentee, there's little chance you'll be able to explain something big. Code reviews are also a great way to build rapport and trust with your mentees.
When you have the feeling that something is impacting your mentee's work, David's personal preference is to schedule in a call and have a chat. He uses that to figure out how they're feeling and what their frustrations are. He keeps this sentence in mind: “It's not what you've done. It's what you do next.” If you've made a mistake or aren't feeling well, that's okay. It's what you do next that matters.
All this requires patience. Kasper said there's no magic bullet to muster up enough patience. It comes with experience. It's also experience that allows you to figure out where someone's head is at when you talk to them.
Additionally, there's always an unknown, unavoidable factor in teaching someone. Sometimes, you just don't gel well with a mentee and there's nothing to do about it. Wrong timing, not the right fit for a project, not the right chemistry. Not every mentoring experience will be fantastic and you need to be okay with that.
People learn from you passively too. How you present and conduct yourself on public channels such as GitHub or company calls influences the people you interact with.
Josh said that you need to create a culture where people feel that it's okay to make mistakes. The questions you ask when something goes wrong can create or destroy such a culture. Admitting your own mistakes, for one, goes a long way toward a positive, humble culture.
Nikole always keeps in mind that she can't ask anyone else to do something if she hasn't done or isn't doing it herself. For example, it's harder to encourage people to work on open source projects when you've never made any OSS contributions.
One of the better ways, and one of the scariest too, to help a team grow is to give them Slack journals where they publicly write what they're working on and how they're going about it. It's scary, because it opens up someone's thought process. How are they trying to solve a problem? What steps are they taking?
Josh said that a Slack journal adds enough accountability to have you question why you're doing things a certain way. This, in turn, puts you in a better place to learn and look for better ways of doing something. Other people can also jump in and help you along the way. Without a Slack journal, it's rare for someone to show their thought process for a particular problem.
Nikole helps out in her local community because she saw that only 0-2% of new tech graduates were women. This wasn't the future she envisioned twenty years ago, nor the tech scene she wanted to live in, so she decided to help and address some of the problems that were disproportionately affecting women.
When the problems in the world seem big and overwhelming, focusing on what you can do in the ten square miles around your house makes it feel as if you have more control and a bigger impact on the world.
If you enjoyed this interview, please go have a look at our bigger post where we summarize the whole conference through audio snippets, quotes, and Slack highlights. There's a lot more to be found there!
Over the next three weeks, we will publish similar summaries of the other days of FwdConf and link them below. See you soon.