Never Be The Training Wheels

When we decided it was time for our daughter to learn to ride a bicycle, we did the expected thing and got her a Cinderella bicycle, training wheels included. She was an eager student and we got her going quickly. While she could easily get down the street, turning was very slow and the falls were made more violent by the training wheels creating fulcrum for the bike to tip over. I raised the training wheels to give the opportunity to balance with both off the ground and turn more easily, but still provide some guardrails to prevent tipping. But it just didn’t happen that way, she was comforted by the feel of the training wheel on the ground, meaning she was leaning on the verge of falling by default! I finally talked her into trying without the training wheels at all and I would run along side. With no training wheels to feel, it didn’t scare her when they weren’t on the ground. She did great and rarely fell after that. When it was time for our second child, I got a bike from goodwill and removed the drive train, just wheels and brakes, no cranks or pedals. (they call this a strider bike now) I just had to hand it to her and say, “go” and she was riding all over. After a short while, I either got another bike, or put the pedals back on, I’m not sure which, but she didn’t have to overcome the balancing fear, she just had to learn to pedal and it was pretty much instant success.

training-wheeled bike

I realized early in my career that this was an effective analogy for mentoring software engineers. A lot of the writing on mentoring I’ve seen is very much targeted toward the least common form of mentoring, which is where the mentee approaches a more senior engineer and asks to be mentored, especially within an company sponsored mentorship program. I’m sure these are valuable relationships and programs, but the more typical situation is where a team lead is responsible for growing the skills of more junior engineers. That’s where I’ll focus, not that it isn’t applicable to other forms, just giving a point of view.

unstructured mentoring

An active development team has more than enough opportunities for organic mentoring. Fortunately many of these opportunities come out of healthy team activity.

Code review is best when there’s more than one reviewer, so you will see more junior devs performing reviews (they will need encouragement to start doing this). This is a great way to notice progress, the comments will become more helpful and insightful. Use it as a conversation starter, ask why they made a certain comment or play devil’s advocate for the opposing point of view. Avoid correction, unless it’s an obvious error. It’s great to have these exchanges in the code review itself because it normalizes active code reviews. Sometimes you will want to move comments out of the review, for two reasons: it can increase noise in the review and may distract from the work at hand; not everybody is ready for this kind of open critique. If discomfort is the reason for not putting it in the review, try to ease it in, make sure to not get defensive yourself. Most code review systems allow you to tag people, this is a great tool in your own code reviews to ask for opinions or alternatives in tricky code. Another great tool for making code reviews more comfortable is conventional comments, being totally clear about the kind of comment can seriously improve the tone of the conversation.

The engineer’s job is not strictly coding, so it’s good to extend mentoring beyond that as well. A good exercise is to present a design for a feature or system to the mentee and task them with breaking it up into deliverable stories. Give feedback on the proposal and see it through to completion. Creating the backlog is one of those things that when done well seems obvious, but it really takes some practice and analysis. Once the mentee has gone through this work on their own, it will draw their attention to the patterns that you use when completing those tasks. Like the code review tactics, part of the benefit is increased engagement. People who have written stories are much more likely to engage in refinement sessions.

Another distinguishing characteristic of effective software engineers is that they are able to collaborate with other teams and functions. In larger companies these opportunities present themselves quite often. Involve your mentee in these meetings and find tasks they can help with or complete on their own. Eventually, let them take the lead and provide support. It is important in these collaborations go well, as this is often where people outside of the team actually see engineers’ capabilities and reliability, make sure your mentee is successful, this is one area where you don’t want them to learn through failure. As such, this is an area where you might hold off for a while.

strider bike

The point of the strider bike is to provide incremental success and comfort. This is also the surest path to growing an effective developer. The strider bike isn’t reading documentation, it’s building software, but software that they are ready (or nearly ready) to develop. So, don’t waste any time in assigning real tasks, but take care in choosing the tasks. On the strider bike, the kid will fall, but mostly they will succeed, it’s the possibility of the fall that gives the success power. If the tasks given are too simple, they won’t learn and they won’t feel like they’ve accomplished anything, be sure to give enough space for failure, and if they are careening toward a failure, let it happen within reason.

Not every task needs to be a challenge, after some growth, let them do some newly easy tasks to burn in the progress. In other words, let them coast. Doing something with ease that once was difficult is tremendously satisfying and allows you to observe the adjacent activities and consequences. Maybe they will notice a more efficient approach, or a way to reuse the initial work, making subsequent work less intensive.

hold onto the first aid kit

A lot of this sounds like maybe the senior engineer isn’t entirely needed, and without time constraints, that might be true. But the fact is there is usually some urgency around the work that is being done. Also, when learning, we make a lot of mistakes, which is good, it’s how we learn. But, the truth is, some problems are easy to get into and very hard to get out of. This is where the value of seniors is most obvious (not necessarily most valuable). Having someone who has made a similar mistake before is highly beneficial, it keeps management calm, it keeps the person who made the mistake from spiraling in self-doubt (hopefully), and it keeps someone close and trusted to help resolve the issue in a timely manner.

now they can teach someone else to ride

The highest goal of mentorship is to create a mentor, the lessons the mentee has learned can be used as they progress into a senior, to help the new juniors. To keep with the recurring theme, this too doesn’t need to wait until they are entirely ready. Encourage them to help the most junior team members with the things they know best, as you’ve probably learned along this journey, you learn a lot from teaching, and so will they, so loosen your grip on the bike seat, just nudge them when they stray… and absolutely never be the training wheels.