A Mentor's Crossroad

Being an experienced developer puts me in a unique position: I am finding opportunities to mentor while still absorbing the lessons of those around me. The best ways to be a supportive figure in someone's coding journey is something fresh on my mind because I am still crafting my own journey. I can take mentee thoughts like, "I wish so-and-so would take this approach...", or "I feel like I could tackle this task if I had support in the form of..." and immediately apply it as a mentor.

This perspective makes a round trip, too. I encounter mentees whose inviting demeanors and openness to learning opportunities make assisting them feel like leisure and not work. These folks also give me guidance on the adjustments I should make to project the same rewarding experience to those who I turn to for some coding wisdom.

These are some of the lessons I've learned from being able to see both sides of the coin:

Mentoring Tips

1. Ask questions
   Just because I have more coding experience, doesn't mean I know the path my mentee should be taking. Asking questions gives me clarity of the situation so I can proceed with the best recommendation. Does the person you are helping need to understand the root of their problem or do they need to know how to track down what the root of their problem is? Maybe they don't have a problem yet but they are just unsure of the task at hand. None of these scenarios are quite clear when you are just looking at an error message or a block of code. Your mentee may be shy to speak or just not know where to begin after the words, "Can you please help me" are uttered. Also, asking questions prompts the mentee to practice speaking to their technical decisions/intentions. I, myself, am a person who is better at writing than I am at speaking in all of the subjects I'm familiar with (not just web development). When I ask my technical cofounder to help me troubleshoot a feature I am building, even though we work well enough together that he could probably read my mind, he does not let me get away with saying my favorite generic word: "thingy" when describing something. This mini-torture has been really helpful for me to develop my speaking confidence, and I hope to instill that in my mentees as well.

2. Demonstrate preference without contempt for other options "Vanilla JS all the way- who even uses Coffeescript anymore?" "You can forget about Heroku- Docker is the future" When you have strong statements like this, you risk keeping your mentee in a state of analysis paralysis because they are not sure which languages/tools/frameworks to initially commit to. To really grasp what you are working with, you need to spend real time on it but having someone super determined to tell you you've made the wrong decision is not helpful. Your opinions come from a good place and they should be expressed but avoid making end-all sweeping statements about it because the moment you tell them not to bother with erb because haml is efficient, clean (and gorgous and I love it)- suprise! They will come back to tell you that their new job has erb-only apps. Developers can be nuts about their craft, myself included, but real world workplaces are not always cutting-edge and there is a value in learning something even if it is not the new hotness. The most important thing to note about this is that if you reduce the haterade on the options you don't like, you create a more supportive community that we all want to be apart of for years to come.

3. Devote real time and attention
   When I make time to code with someone who I might be mentoring, I bring a project with me that I could work on but I do not carry the expectation that I will get super far. Switching context from one codebase to another takes time even just to assess the situation. I don't ever want to rush the person I'm helping because having someone watch you type is anxiety-inducing enough- there is no sense in adding extra pressure. In the end, the time I spend helping really comes back to me three-fold. I get to review information I may have known already, I get to practice applying a solution in a different context, and I've created an ally I can call on to help me if a similar but more complex issue arises. A win-win-win... situation. =)

4. Don't be a dick
   You are tired. Mentoring is not the only thing on your plate. Still, do not be a dick. You obviously know enough code to advise someone about it so you probably like coding. Do not ruin it for someone else. You've had good mentors, and you've had shitty mentors. Be someone's good mentor. (NOTE: I was going to omit this but it's true, and it's a good reminder for myself to stay positive/patient/helpful).

5. Avoid hesitation when mentoring someone you perceive as more senior than you
   Someone programming for twice the duration you have does not know more about every subject than you do! Get that in your head. Programming trends are constantly evolving, and even the most genius of pairing partners you meet at a meetup will not know everything. Be the open ears/brains that this person needs. There will be situations where you are more seasoned than they are, and even in the ones where you are clearly not, your get-to-know questions about the functionality and structural hurdles that they face are helpful and will guide them. The community needs you. Get out there!

Menteeing Tips

1. Allow streams of consciousness to complete
   When mentors are delivering you information, they are trying to frame the issue for you. Sometimes they have to start on the way outer edges because they are unsure of your current knowledge level and they do not want to skip over any gaps you may have on the subject. Other times that is just the way they speak- some of us speak in short-precise sentences and some of us speak in a long-form story-telling-by-the-campfire sentences. In either case, waiting for your fellow developer to finish their thought allows for them to maintain their flow and deliver the solution. If it happens to not pertain to the specific issue you are trying to troubleshoot, you will have another chance at rephrasing your question afterwards. This gives you a chance to learn something extra (or review something you already knew) while your mentor is arriving at their solution.

2. Reiterate the task at hand, not just the specific problem I am facing
   Maybe you have been trying to understand how to get the specific height of all the dynamic elements in an ad you are making so you can expose the right distance from the top of the window. And maybe you have been trying to figure out the correct formula for an hour. Start answering the question "What are you working on?" with "I am trying to implement a 'Read More' banner on this ad" instead of describing the exact method you are using to accomplish this task. This gives mentors a bigger picture of your task- helpful especially since they have not been as intimate with these lines of code and feature requests as you have been. In case you are wondering, I abandoned the exposure-by-height-of-all-elements strategies and instead chose a click-to-show-blocks strategy. The Javascript was way less badass but the jQuery used to implement that let me move on to something else.

3. Show-and-tell your code even when you don't need help
   Keeping up the dialogue about your tech stack even when you aren't running into any issues is a great way to pick up on little nuggets about programming you may not pick up on by yourself. More often times than not, I hear about how someone has built what I have built but in a different language/framework. These recounts usually come with a compare/contrast of how that implementation worked compared to what I did. Learning from other people's experience is general good life advice but especially applicable to an open-source community.

All in all, I would say- get yourself out there and mentor several people and seek out a handful of people to mentor you. Mixing up the partners you turn to for in this mentor's crossroad will widen the scope of your effectiveness as a developer and a teacher. Software is ultimately about people, but those people aren't just your end-users. They are also the people who you meet along the way as you cross paths.

This week, as I dusted off the list of "pending" posts I've been meaning to start/finish (this one was started in August of 2015), my husband registered for his own GitHub account so I really hold these tips close to my heart. I'm not sure where his coding journey will take him, but I'm happy to be a partner in it in the best way that I have learned to be.

Originally published at rubynista.com on October 14, 2016