Best practices for guiding new coders

As the new year progresses, many free and open source projects are turning their attention to various formalized mentoring programs, such as Mozilla's Winter of Security, Outreachy, and (the program with my favorite name) the X.Org Endless Vacation of Code. Patterned after the success of Google's Summer of Code, these programs give many new programmers a chance to gain firsthand experience working within successful FLOSS (Free/Libre Open Source Software) projects and the projects themselves access to fresh talent.

Being a mentor, though, is more than just pointing a new coder at your code and letting them run free. Even the most talented person needs guidance as they work. To complicate matters, being a mentor is not the same as being a supervisor. Mentors are there to lend experience and guidance, a sometimes delicate balance that needs to be done correctly so both mentor and mentee achieve the most benefits. Having worked with some of these programs, and as a mentor for others in the past, I've pulled together some of the methods and ideas I've picked up along the way.

There are many reasons why mentoring is a positive experience for all parties involved, and what works for you and your organization may be different than what works for other communities. For Red Hat's OSAS (Open Source and Standards) team, mentoring works for us because the process folds well into the community onboarding practices we try to implement across the free and open source projects with which we work.

In OSAS, onboarding is made up of three key aspects:

• Explaining what a project is
• Giving access to the project's results
• Showing how to use and work with the project and its results

Mentoring is part of the third aspect of onboarding in OSAS; it is part of demonstrating how the project works and how to work with it. While documentation and best practices are certainly strong tools to work with, many projects still have their own special tricks and quirks that aren't readily communicated without direct hands-on experience. Mentoring incoming developers, even informally, is a great way to improve onboarding efficiency.

Mentoring, therefore, is definitely a thing; you just need a plan and, of course, time. Mentoring requires a substantial time commitment and the willingness and ability to take on a mentoring role—there are no shortcuts. Before this daunts you, however, keep in mind that the rewards for both you and your mentees are typically well worth the effort. The impact from a positive mentoring experience can last far beyond the immediate project, and even decades into the future.

I myself am an example of such an impact. Straight out of college, my first boss shaped the way I approach writing and journalism, and I carry with me every day the lessons he imparted to me at a small-town newspaper in western Indiana.

Mentoring a student requires a combination of passion, responsibility, and patience. Plus, a mentor should be willing to engage with mentees throughout their learning process. The number one thing to remember when mentoring is that even experienced mentors can improve, so always be ready to seek help. The flip side of that, if you are setting up a mentoring program in your community, is ensuring that your mentors have resources on which they can rely: literature, forums, and access to other mentors. There is always going to be something new that might throw a mentor off, and having a resource of people to discuss such issues with is very important.

Another big challenge is to make sure that all participants in the program are encouraged to sit down and go over expectations. Even if the project in question seems as straightforward as "add a plugin to open a new media file type," remember there is always room for ambiguity and confusion.

A typical example is when I get a call or an email from an old colleague about working at Red Hat, and if they have not been explicit, I have to start wondering why they asked you that. Does this person want to work for us? If this person is one of my journalism colleagues, is he or she looking for a story? Or is this person just curious about how I am doing and making sure I never come back? Understanding exactly where a person is coming from is going to avoid a lot of confusion and awkwardness.

As the mentoring relationship progresses, you will need to make sure that there is indeed a relationship there. Mentors can have a litany of advice they want to deliver, but if it's not tailored for the person they are mentoring, it may not be effective.

At the bare minimum, find out their working style, their dream gig, and goals for their current position, but find out about their personality, too. Are they detail oriented? Then nudge them away from abstract elements of a project and towards the tactical implementations. If they like to plan and strategize, then recognize they aren't going to be at their best doing a bunch of data entry tasks.

When problems crop up, and they will, try to avoid going straight to the solution (unless the problem is something like "my computer is on fire"). Try to avoid even relating similar examples that may have happened to you, despite that approach being a favorite method for setting up an empathetic dialogue. Being empathetic is not the worst thing in the world, mind you, but remember you are there to help mentees solve their own problems and build solution frameworks that will guide them conceivably for the rest of their careers. Instead, ask the mentee more questions and dig into what the issues are. Help them see all sides of the issue. Ideally, they will start to see the solution on their own. Even if you do have to give them more explicit guidance, you will have more information for yourself so you can formulate a better response.

Finally, the one thing that all mentors need to remember is this: your mentee is not you.

As a parent, it's easy to want your kids to be better versions of you, but it is critical to remember that they aren't you. The best you can do is lead by example and point out the really stupid mistakes you've made. Thus, I am reasonably confident my daughters will never be involved in a cow-tipping incident, but they will not be carbon copies of me.

On a much smaller scale, the same thing applies to mentoring. You want to impart your experiences, not mold little Mini Yous. My first boss I mentioned earlier was a chain-smoking, crusty, SOB but he didn't give me those attributes. Instead, he gave me a sense of fairness, an eye for detail, and a stronger work ethic, and for that, I will value my time with him forever.

Working with your own students can give you that kind of impact, too. Share what you know, but respect who they are. Who knows? As a mentor, you may learn something new yourself.

Any day we learn something new is a darn good day.

Brian will be speaking at SCALE 15X on Mentoring 101: How to Be An Awesome Community Mentor.