Tag: mentoring

Be a mentor

This is a guest post from Akira Brand. Enjoy.

Dear New Developer,

Be a mentor.

Seriously. Find someone a little bit behind you in their journey and mentor them. All you need is an hour a week. Heck, even an hour a month. Work through exercises and projects with them. Tutor them in an Udemy class. Sign up to mentor hackathon participants. Find a code school you like and mentor their students.

You may not think you know a lot right now, but you’ll solidify what you do know in profound ways through mentoring. You’ll find every gap in your own learning that you didn’t know was there, and what’s more, be able to fill it. You’ll start to deeply understand the context behind certain problems, as well as the grander architectural and design systems that underlie all good software.

You’ll learn why things you didn’t care for or regard as important before actually are (for me it was pseudocoding), how to problem solve in a team, and build empathy for not only the end users, but for your mentee, and, for yourself.

Be a mentor. Find someone who needs a teacher and be that life changing person for them. It’ll be one of the most fulfilling segments of your career.

Good luck, and remember to breathe!

Akira

Akira is a full stack developer currently working on building a JavaScript bootcamp with Emeritus. They love to digitally nomad and are currently in Boulder, CO.

How to get the attention of a busy person

Dear new developer,

This post talks about how to ask for mentoring, but the principles apply to getting in touch with any busy person. Busy people are by definition busy, and get a large number of emails and requests every day. (Here’s a VC talking about the difference between ignoring and not replying, and how they look the same to a sender.)

The key is that you as the requester need to put in some effort. From the post:

In other words, when you asks for a busy person’s time for “mentorship” or “advice” or whatever, show (a) you are serious and have gone as far as you can by yourself (b) have taken concrete steps to address whatever your needs are and (optionally. but especially with code related efforts)(c) how helping you could benefit them/their project.

This effort on your part shows that you are serious. It qualifies you. Especially if you persist. (Now, you can’t persist to the point of annoying the person. There’s a line between persistence and bugging someone. I always preface any email I send to someone asking a favor with ‘hey, feel free to tell me to buzz off’, and I mean it.)

And

I hate to sound all zen master-ey but in my experience, it is doing the work that teaches you what you need to do next.

That doesn’t mean you can’t learn from reading (otherwise why have documentation or even this blog!) but that you need to actually try things outlined in docs. Even just typing the commands of a tutorial (instead of copying and pasting) will help you understand what you are doing.

The whole post is worth a read.

Sincerely,

Dan