What I learnt in half a year of mentoring

Published Aug 07, 2017

In November past year I started working with Roy, a very nice guy that (at the time) wanted to improve his Ruby on Rails and ReactJS skills. He would be my first mentoree and, as a matter of fact, the first one ever learning anything from me.

A couple days ago I was contacted by another possible mentoree and at this point, before my second adventure, I think is a good time to review how things have gone, what worked and what could be improved. It's been more than six months since then and a lot of things have changed.

My initial expectations

Before starting with Roy, I had some ideas of what I was expecting from our sessions.

The first thing I wanted was a long term relationship. I don't think I'm good enough to make any kind of impact in someone in less than a couple weeks. I'd need more time to be able to transmit anything.

The second thing I wanted is a professional focus. Although it's alright to learn programming for sake of it or to focus on computer science, what I really like is software engineering. I'm looking for someone whose objective is being able to build fully functional systems.

On the other hand, I wasn't really sure on how I wanted to conduct the sessions. Would we do some pair programming? That would require him to know something before hand. Would the old method of giving and reviewing exercises work? It never did for me in University. Should we focus our sessions on topics to learn or projects to create? No. Fucking. Clue.

Admittedly, that was my first mistake. Not knowing exactly how I wanted to conduct the process leaded to a very sloppy first session. I made all the decisions on the spot, after a quick chat with him and just played with it. Roy was smart enough to follow my rhythm with no problem and we were able to improve the feeling by the next one, but a better preparation in my end would have made the process smoother.

I think all this could have been prevented with a prescreening. If I had had a fifteen minutes chat with him before the first session, I'd have had a good feeling on where he was at and what he was expecting and I'd have been able to design a plan for the beginning. That's the first lesson I learnt!

Our first contacts

Roy had a couple unusual qualities that I wasn't expecting before hand: He already know the basics of programming (in fact, he had a couple years of experience) and he was working professionally in the field. In fact, his company was sponsoring the process. I came to realise quickly that most people looking for a mentor aren't outside the industry but inside: As junior developers wanting to improve their skills or in related positions (business intelligence, TPM, web designers) trying to make a career move.

Because of his background, my first decision was to do pair programming sessions. We would pick a project to build (in our case, a forum) and we would go through the process of building it together.

I chose pair programming because it worked with me. My "mentor" was one of my early managers, Ken Demarest, and every time we'd sit together and work in a problem hand by hand I'd leave with a handful of new knowledge and the feeling that I was little bit better. I'm not sure it's the most productive practice in a work environment and I'll argue with anyone claiming so, but it's definitely a brilliant way to transfer knowledge.

And that was my first victory: I think that approach worked very well with us. The process is:

We start by discussing the problem we were trying to solve this time, I explain briefly how to do it and maybe put a couple examples and then, with he sharing his screen, we implement it. If he gets blocked, I help him solve the problem, but otherwise I let him continue still he's finished. After that, we discuss his approach and how it could be improved.

One of the difficulties that I faced, specially at the beginning, is knowing when to participate. Should I dictate every step? Let him go? Correct errors as I saw them? And what about the style?

After some try and error, I learnt a couple tricks:

  • At the beginning, dictating is useful. Specially while learning a technology or technique that is unknown for him. Just saying what's expected, let him type it and discuss it after works very well. It gives him the chance to see how to approach that kind of problem and the feeling of the solution.

  • Dictacting doesn't work past certain point. A couple of times, Roy actively asked me if he could solve certain situation by himself first. That was a heads up for me: I wasn't giving him enough chance to test what we were learning together. Once he saw a couple times how to test an endpoing in Rails, he wanted to write the next test. Fair enough! Letting do so helped me to see what he understood and what needed a quick review.

I was very pleased to confirm that this approach works. After a couple times going through the process of designing a solution, he surprised me a couple times by pointing out beforehand what code needed refactor and how it should be done or seeing the correct pattern to use in certain problems. That was very rewarding to me: It meant that he was getting something from our sessions.

Forgetting about the technologies

Although the original idea was to work on Rails and React, I wanted to make our sessions technology agnostics. I didn't want to leave him as a "Rails&React developer" but as someone who is able to learn something new and build projects with it. Knowing how to break down projects, how to understand a type system or how to write testable code are far more important skills.

At the beginning that was a little bit difficult, specially because I didn't how to push our sessions that way. However, the fact that Roy had previous working experience and already knew the basis of the technologies we were using, helped a lot in this matter. Slowly, I tried to focus our time on how to engineer projects and how to pick tool rather than mastering the hammer and the saw.

Something that helped me here was introducing new things in the equation: "Ey, what if we convert our web app in a phone app?", "Ey, what if we put all this in a Docker container?", "Ey, what if we use typescript?"

That was my second victory. I think that taking a more elastic approach in what to learn helped us a lot. I knew when something very small (and unplanned) happened:

Usually, when a problem raised during our sessions, my first step would be to go to the documentation, read about the part of the code that was causing an issue and see if the usage matched what we were doing.

Well, one day, Roy had the documentation opened before me! That may seem anecdotic, but it was an excellent signal for me: It meant that he was learning how to approach a new technology.

TL;DR: We started developing a forum with Rails and React. We're now creating a system to classify blog posts scrapped from blogger by subjects using Spark/Scala and Scrapy/Python. Switching technologies gave me the chance to teach transferable skill that aren't tied to a particular language or framework.

The art of debugging

I don't want to leave without speaking about this. I think that most of the time we spend together, we spend it debugging errors. And we have seen them of all colors:

  • Typos, variables without the expected content & co: Specially when programming with Javascript. And I think that was a big lesson for us: A compiler would have caught that. In fact, when we started using Typescript he (and I) was very happy about the results in that area.

  • Third party errors: A couple times, we found bugs in the libraries we were using. That gave us a lot of cool opportunities: First, to learn how to properly administrate dependencies and second to learn how to submit a pull request with fixes. He even made a contribution to the repository DefinitelyTyped to fix one of the problems we were having.

  • CORS problems. Because no one can escape CORS while working in web development.

  • OOM (Out Of Memory). When we moved to big data processing, we faced in a couple cases problems with lack of memory. That gave us the chance to learn how to analyse our solutions and how to optimize it. And if it can be optimized! In a couple situations, we simply had to deal with smaller data.

While it can be frustrating to spend time chasing errors, I think it's really valuable. Specially when you're trying to learn how to actually build software. Let's face it, for us working in the industry, debugging makes a big part of our work. It isn't glamurous, it isn't funny, it isn't recommended for your health, but it's necessary. And knowing how to read an stack trace, how to identify what part of the code is involved and to reason about errors is one of the most important skills that a developer should have.

What I know now

So I'm about to start with a new mentee. After all this time, what did I learn?

  • Choosing a long term relationship was a good idea. I don't think our agreement with Roy would have worked as well if we had only two or three weeks. I'm far from being that good!

  • Prescreening is important. Knowing before hand what to expect, what they know and what they expect to learn is vital and helps making the start smooth.

  • Don't focus all your energies on technologies. Just learning Rails and React doesn't work long term. It's often more important to know how to learn a new stack, how to debug for a problem, how to read code that isn't yours, how to structure a project or how to differenciate trade offs in designs.

  • Adaptability. I, as a mentor, should know how to adapt to the person I'm working with and the expectations that they have.

I feel that Roy had to suffer a bit of my inexperience in the subject, and I apologise for that. At the same time, I think we both learnt a lot in the process and I can’t wait to apply what has been learnt in the new experience.

Discover and read more posts from Agustin Chiappe Berrini
get started
Enjoy this post?

Leave a like and comment for Agustin

18
5
5Replies
sheriffderek
a month ago

Thanks for this story of experience. Too many mentors on this platform just want to fix your problem and charge for the hour with no face time or explanation. Many people probably think this is great because they get the thing they are stuck on fixed… but in the long run, they are really missing out on a solid foundation that will save them thousands of hours. You sound like a great mentor. Keep up the good work. : )

Ed Mays
a month ago

Excellent topic, you raise some great points!

Prescreening is vital, not only to assess the student’s needs, goals, and skill level, but also to make sure we’ll be a good fit. I also use screening sessions as a way to help introduce students to the CodeMentor platform if necessary.

I also agree that long-term mentoring holds much more value for students than “I just want to learn everything in two weeks”. The fact is, software engineering is a complex subject that requires not only 1:1 instruction time, but also time to mentally process that information and let it sink in. Rushing skips that ‘sinking-in’ process, so most of the learning gained from a session rapidly fades.

That said, I have had several good short-term experiences with working engineers who needed to get up-to-speed on a specific topic (i.e. IoC, Unit Testing, etc.) - they already had strong foundations and clear goals and were just looking to apply them in a new context, so the learning curve was diminished.

Anyhow, great points, and good luck with your future students!

Architectify
2 months ago

Thanks for sharing what you have learnt, it is appreciated. What would you suggest for men-tees without previous experience ?

Agustin Chiappe Berrini
2 months ago

Uhm, good question!

I think my advice would be: Roll up your sleeves and build something. Researching too much in Internet about trivial related with programming or looking for excuses on why you will suck (of course you’ll suck! You’re a beginner!) won’t work. But build shit? That’s the easiest, most effective and funniest way to learn.

Ed Mays
a month ago

Just to add to Agustin’s response - some related suggestions for mentees starting from ground zero or thereabouts…

  • Take some time to learn a source code control system (GitHub, etc.), and use it as you’re learning. It’s a helpful safety net as you’re learning to code, so you don’t lose hours or days of work because you accidentally went down the wrong path. This will also help teach you habits that are expected in nearly every professional coding environment - it’s never too early to learn good habits :)

  • Agustin is right about sucking at first, but that’s basically why we practice things - to improve! The key is to recognize areas for improvement (for example, “Hmmm, this class has 2975 lines of code in it, it’s sure hard to find stuff when I need to make changes”) and then learn to improve from there (“Maybe I should refactor this class to give it fewer responsibilities and improve maintainability.”) It’s a gradual process, but if you keep building stuff, you’ll see improvements.

  • Another good way to improve is through code reviews (also made somewhat easier via source code control). Having another set of eyes on your code can help guide novices through more complicated topics by actively suggesting improvements. In the longer term, you’ll also be acquiring another professional skill - many shops use code review as part of the dev process and knowing how to give and receive feedback is important.

Show more replies

Get curated posts in your inbox

Read more posts to become a better developer