What Do You Look For in a Mentor?

twitter logo github logo ・1 min read

Front end engineer here, looking to make a positive impact on the growth of new devs 💪

When you first started your programming journey — what are some of the concepts/workflows/teaching techniques that your first mentors really knocked out of the park, and why?

If your experiences haven't been super positive, what would make the learning process easier and more enjoyable for you? What would you change about the industry to make it less intimidating and more empathetic?

Let's hear it in the comments!

twitter logo DISCUSS (12)
markdown guide
 

One of my favorite techniques was when my mentor asked me to explain what I thought was happening when I wanted to learn something or needed help figuring something out. Let’s say it was a weird bug. I’d explain what I thought the current state should be, and as I explained it, often the false assumption would become clear. Or even after learning a new concept, I was asked to rephrase what we just talked about, so I could quickly address gaps in my understanding or know where to go read more.

On the other hand, code reviews were really intimidating. It felt for a while that everyone just wanted to rip my code to shreds just to prove how much smarter they were. That of course was not the intent by the reviewer, so we made adjustments to the onboarding process to avoid people feeling overwhelmed in their first few months. 😁

 

One of my mentors back in college emphasized the importance of commenting so that my teammates can understand my code better and so if I need to revisit code later, I waste less time familiarizing myself with my logic again. That has helped me a lot and I share this with my mentees!

 

My first mentor was able to impart a lot of lessons to me but what I most remember was the "divide and conquer" approach to fixing bugs. I was pretty new to software development at the time and was having a hard time pinning down complicated bugs. It revolutionized how I approach things now and applying it outside the context of fixing bugs but in dealing with most tasks.

 

Without being too specific:

  1. Attitude. Obviously, it's important for a mentor to be welcoming and open to questions. But also, there must not be any noticeable frustration on mentor's part, like when I don't know something or I didn't got it the first time. It's the little things - like reacting by not reacting. Mentor must be excited to show me something, or to go deeper with their explanation. Otherwise I might be afraid of not knowing.

Reacting by not reacting:

orangutan

  1. Follow a tried skill-acquisition techniques

Path to mastery has been studied for quite some time by the eastern philosophy. Look at shuhari or a more 'formalized' model like the Dreyfus squared. Dan North gave a great talk about this.

 

One of the things I think I probably wasn't all that great at early on is knowing when to ask questions. It can be hard for a junior engineer to understand when they should be trying to sort something out on their own, and when they should ask for help. This is especially true for people who feel nervous about asking senior engineers for help, or worry that by asking the question they will sound incompetent or expose their ignorance (i.e., imposter syndrome).

The very first thing I try to teach, now, is exactly that skill - knowing when to ask for help, and that's expected that they do so. In addition to being a fundamental skill for growing as a junior engineer and being a member of a team, I think it can really help people feel more comfortable asking for and receiving help when they need it, reducing their stress and hopefully making them feel more welcome and like a valued member of the team :)

 

Wait, ok, so when is it not a good time to ask for help?

 

I think it's important to spend at least few minutes "googling around" or rubber-ducking the problem to see if you can figure a solution before asking a mentor about it, so you're not using them as a crutch. This is something you can work out with your mentor, like, okay, how much time should I spend researching on my own before considering myself "stuck."

 

What I found really helpful with a mentor was to highlight what you want to learn from the beginning. In my case, it was Node.js.

My mentor set up a project on GitHub with the barebones and a lot of comments in the files so that we could then go through the Node.js idiosyncrasies together.

There would be tasks for me to work through, and this would be utilised via GitHub Issues too. If I had any questions about tasks, I could contact my mentor or use the issue's comments to ask questions.

Once I was happy with what I set out to do in the task, I would submit a pull request and flag my mentor as a reviewer. It is in the code reviews that I found I really learnt a lot, and try new things that I had not considered along with the best practices.

It is with this approach that I feel I have really progressed further working with Node.js than I would have done if I had studied on my own. Having a mentor is immeasurably valuable and I for one am really grateful to my mentor for taking the time to help me learn and become a better developer in the end.

 

I have recently used gitHub for the first time and made commits throughout a whole project without taking advantage GitHub issues to learn with my mentor. Thank you for sharing this :)

 

Mine, he is a friend and the first technique he told me of was the fact that HTML is the structure of any site.
The one thing that would have made it easier and enjoyment to me, is the privilege of having a laptop of mine, so we could be coding together, since he was also a beginner.
Create more hubs with good management system.

 

There is a lot of pressure to learn and "stay on top" of things. I have not been able to make a lasting impression in the industry except AS a mentor so far. That experience in general has been draining, and I have been trying to motivate myself to stay fresh and keep learning.

 

My favorite professor to date was the one who taught me malloc in C, along with how to manage memory pointers and references in general.

Classic DEV Post from Jul 27

If You Don't Know, Now You Know - GitHub Is Restricting Access For Users From Iran And A Few Other Embargoed Countries

Please help our cause against modern-day discrimination

Kim Hart profile image
Front-end engineer at JW Player, creative technologist, #BUILTBYGIRLS mentor, SDSU & General Assembly grad, ISFJ, west coast kid, beer fan
Join dev.to

Better understand your code.