Trust me that this picture of clouds isn't randomly put here

In my career so far as a software engineer I have had 3 opportunities to be a mentor for someone that is more junior than me. Sometimes this junior-senior status is established not necessarily by the capabilities and skills but more by my length of stay in the company. This was especially true when I worked in Japan that is known heavily to promote a seniority ranking of some sorts, implicitly or explicitly.

Considering that I have only been professionally in the field for 4 years, with no previous background to software programming before my undergraduate, is something I find a bit surprising even for myself. I feel blessed to have had the opportunity so early in my career and in this blog post I go over my experiences and thoughts on my role as a mentor

The first mentee

I was asked to mentor a new colleague six months into my first professional full-time career as a software engineer. By standards of total working experience this colleague was actually more senior than me, but I just so happen to have worked in the company sooner than him. This mentee was also quite adept in his tech skills, so aside from a few pointers about the team dynamics, projects, system overview I can’t actually remember any specific piece of technical knowledge that I felt I was able to impart. Actually I remembered several times where I was surprised with what he showed me, for example a specific setup that he had for the terminal-based text editor Vim. I have no shame in saying that I actually learned some things from my mentee.

My relationship with this mentee was more akin to colleague buddies. We were both close in age and was very techno-optimistic (I’m less techno-optimistic now) and think that technological advancement is always the best. We thought that impediments to technological progress is always bad. We bonded over the frustration of not being able to use and try out more modern techniques or tools, because management would say its too risky. We would shrug them off as an evil that we needed to live with and begrudgingly dreaded whenever we had to work with parts of the system that was deemed ancient (even by the really senior members in our team).

Then, my relationship as a mentor had to end because I was scouted by another team. There is an inherent idea in my head that the success of a mentor is in how much one can impart their knowledge to the mentee and in this view I would say I had done a poor job as a mentor. But I take solace in thinking that I was a great and relatable colleague, hopefully.

The second mentee

A bit more than a year into my software engineering career I was again given the opportunity to mentor an incoming colleague. This time, my mentee was actually just freshly started work as a professional software engineer. She also came from a more research oriented background, unlike my first mentee that came from a more engineering oriented background. It was clear from the get go that as a professional she was very green in terms of software engineering standards and the practical skills. I didn’t have to teach her to code, but at times I had to assist her in trying to understand one technical choice over the other. I do not know whether I was actually being an effective mentor, but often my mentee would come to ask me for assistance for her own project. When I had time to spare I would ask how she’s doing and ask if she needs assistance.

Around this time my attitude towards code quality was also becoming more bullish. Still coming off from the assumption that technical progress is important, as important or if not exceeding at times to some business needs, I would at times be hellbent that some technical progress be included into a project. One such example would be automated testing and basic CI/CD, which we were greatly lacking back then. To the credit of my persistence, and also some heavy silences during team debates, gradually my team started to adopt some of the ideas that I kept throwing at them. It wasn’t perfect of course, and it wasn’t smooth or complete either, but it got things going.

Reflecting on my code-quality-hellbent-saga I remember some times when I tried to directly impart this knowledge to my mentee, but uneffectively. I would tell her to revise her code several times, and then may in the end revert some suggestions back. Why you may ask? Well it was because I was also trying to learn the thing that I was trying to impart to my mentee. I had the drive yes, but I was rough in the edges and was more like a bulldoze trying to make its way through instead of being more like a worker ant and learning with and encouraging my mentee. I’m sure my team had their frustrations with me too and probably felt confused at times by my behaviour too.

The third mentee

The third mentee is more recent. In terms of technical skills this mentee is somewhere in between the first and second mentee, still inexperienced overall but not a blank slate. This time I have personally grown with regards to my technical skills from my time with my first and second mentee. I’ve refined my thoughts and experience a bit more and had more time to polish it. I still hold some strong opinions regarding particular positions related to the software craft, but I think I can say that I am more flexible than before.

I also try to be more accommodating and reasonable for my mentee this time, trying to explain things a bit more slowly and showcasing more examples. However, I do find myself to sometimes be a bit impatient with my mentee. It might be because of the experience that I had accumulated so far which makes certain things seem simple and easy for me. So when my mentee is not able to keep up with me I would sometimes say to myself “why can’t he get this quickly?”

But a recent reminder that I’m not always right (and certainly not great) was when I was helping my mentee for the code design of a feature he was working on. At first my mentee suggested a very simple solution that would get the job done, but I said it would be too inflexible for future changes and prone to breaking. My mentee agreed, and tried out my solution, made some unit tests and it seemed fine, until it wasn’t when a more comprehensive integration test was conducted. Turns out I made incorrect assumptions in my solution, and my mentee’s simpler solution would not have run to the same issue as mine. To be honest it did feel bad that not only was I wrong but also I led my mentee to an incorrect solution, but am glad that overall I managed to resolve everything together with my mentee.

Rounding up my experience so far

Reflecting on my mentorship experiences so far here are some things that I have taken away:

It is important as a mentor to actually be able to impart the skills that you are mentoring in. Being close colleagues with my first mentee was good, but I could have been a much more effective mentor and support for my mentee had I had the skills to backup my position
A mentor is a teacher in knowledge, methods and also in conduct. If a mentee is to learn from a mentor, then a mentor should reflect the correct posture to learning and be open to the need for growing themselves
Related to learning, I learned and am reminded that humility is so important, because we won’t get everything right. We need to learn with humility and open to admit our mistakes

To finish things off, there is a proverbial quote I like to say that goes like this (though I’m not sure where of its origins):

Above the sky, there is another sky

There will always be someone better than you, and so there is always room for you to improve and grow, even if you are a mentor and role model for someone