Advice for First-Time Mentors in Software Engineering

Let’s say there’s a new software engineer in your team. Maybe it’s an intern or a new hire. Either way, you’ve been assigned as their mentor or onboarding buddy. How do you proceed?

If you’re like many first-time mentors, then you might spend a lot of time answering any questions they have. Or you frequently help them solve problems, making sure they are never stuck. Maybe you also ensure they always apply the best possible solution. Your intentions are good and you want this person to succeed. Surely, all this effort will facilitate that.

Yet, after a few weeks the mentee seems to have become dependent on you. They might have improved a bit, but for some reason, they don’t seem able to answer most of their own questions. You wish they were more autonomous, and would take more initiative, but for some reason they don’t. What happened? You spent a lot of time helping them. Shouldn’t they have learned a bunch already?

Mentoring is not just about answering questions, providing solutions, or getting people unstuck. It’s an opportunity to help empower someone to make their own decisions, and to understand what kind of decisions are aligned with the team or the organisation. Once they have that kind of understanding, they will be more productive, as they will be making less mistakes, and will think more independently. However, getting there may require you to do some things that aren’t intuitive to you initially.

Let’s make it a bit more concrete with an example of pair programming, which can be a powerful tool for mentoring, if done right.

A bad way to go about it, would be to have the mentor dominate the session, by programming a large part of it, and being very specific in their feedback while the mentee is coding, essentially programming by proxy. The solution might be good, but the mentee likely didn’t learn much. It’s like being taught by a teacher that just read their notes instead of engaging the class.

A better way would be to have the mentee code the majority of the time, and ask them questions to check for understanding. Refrain from providing solutions, and try to help them get unstuck by using coaching techniques such as GROW. Occasionally, stop the coding, and ask them what they think will happen before they execute the piece of code they just wrote. Now, they actively have to think and make decisions. This allows them understand the problem better, and also allows them to figure out their specific strengths instead of mindlessly following your solutions.

The same patterns apply to other areas as well. Do they know why a certain ticket is prioritised? Why is it important? What are some of the solutions they would come up with? Do they understand the interactions between applications? What’s the risk associated with deploying a certain service to production?

Allow the mentee to gradually make more and more decisions on their own. Leave some space for them to make mistakes. This might be counterintuitive, but if you are always there to prevent them from making any mistakes, then you are robbing them from opportunities to learn. Think back of some of the mistakes you’ve made in the past. They probably weren’t the end of the world, but I bet they helped you learn.

Don’t underestimate the mentee, check with what they are comfortable with, and give them tasks that are slightly outside of their comfort zone. Be there to support them, but don’t be overly protective and define clear expectations for them that focus on the outcome, not the way they get there.

Answering questions and sharing your expertise helps, but try to put a limit on it and learn coaching techniques instead of answering directly. If you’re just providing solutions all the time, you risk the dependency issue we talked about in the beginning.

Apply these concepts, and you’ll see that they’ll become more autonomous, more quickly.

4 ways to optimize onboarding of new engineers

Onboarding is a great opportunity to create momentum and get people up to speed quickly. When a new engineer starts, it’s important that they get blocked as little as possible and can quickly figure out how they can be productive within this new team or company.

Here are a few guidelines and things you can do, which I’ve found helpful in the past.

Set up their most important accounts beforehand

Before their first day, make sure they have a company email address. Use that email for invites to the most important applications such as your chat, Github/Gitlab, the issue tracker, etc. This can all be done before they even start, so there’s no reason they should be blocked by this on their first day. Depending on the size of your company, IT or HR should be able to help you with this.

Make the setup of your applications easy

How easy you can make it depends on your situation, and the tradeoffs you have to make, but at least review the setup instructions before a new hire starts, and after they've just gone through it. See if there's anything that can be simplified. Getting an application up and running quickly makes onboarding more enjoyable and means you can start doing actual work more quickly.

Pair them with an onboarding buddy

Assign them onboarding buddy who can help mentor them. If a new team member has any questions, they should be able to get unstuck, the onboarding buddy is there to help them.

It helps a great deal here if the onboarding buddy has some mentoring knowledge, so that they can help the new hire become independent and autonomous while answering their questions. An onboarding buddy with good mentoring skills can help a great deal with helping the new hire in becoming productive.

This also helps include the new hire in team and immediately has them collaborating with one of the team members.

Make it a goal to deploy to production on day 1

Being able to deploy something on your first day feels great and it’s a sign that your onboarding process works. If a new engineer is not able to do that, then more likely than not there are things you can improve in your onboarding process. Use this as a metric to measure your onboarding quality against and keep improving it until people can deploy within one day.

DIV Games Studio

A few months ago, I discovered that an old website, which I used to visit during my childhood days, was back up again. This triggered a bit of nostalgia in me about my experience of learning to code as a kid and how it influenced my life.

“DIV Arena” might not mean much to you, but I’m sure that for quite a few people it was an important part of their life. It used to be the main website where people would upload and discuss games that they made via a program called “DIV Games Studio”.

MikeDX restarted div-arena.co.uk again in 2016

Like many kids, I used to play a lot of computer games, especially Total Annihilation. That game got me to spend so much time on the computer that it drove my dad crazy. He looked at it as an addiction, probably rightfully, and tried to lure me away from it in creative ways, but only with limited success. I think that eventually he decided to change his approach with the goal of getting me to spend my computer time more productively. That’s when he bought me DIV Games Studio.

As I’ve hinted at above, this was essentially a desktop environment optimised for making your own computer games. It offered a code editor, a graphics drawing program and a programming language, all intended to lower the barrier and teach people how to build games.

A screenshot of the DIV Games Studio desktop environment

I was super excited to start making games, so I tried it out immediately, but I was also twelve and didn’t have a clue about how programming worked. The first time I just started typing a story in the bright blue terminal, thinking that would somehow be translated into a game with graphics and everything.

Disappointed when that didn’t work I asked my dad for help again. He kindly told me that’s not quite how it works. If I wanted to learn to make a video game, I would have to read the manual and learn the programming language. Unfortunately, he couldn’t help me either, because while he did learn some Pascal at some point, that was many many years ago. So I set out to learn programming on my own.

Luckily, DIV came with a manual and a tutorial on how to build a game similar to Space Invaders. The tutorial was reasonably easy to follow, and I was able to build my first game. It definitely took more patience than I’d ever needed before, but I did it and it was satisfying. After that, it became more difficult though, because now there was no more tutorial to guide me. If I wanted to do something new, I was on my own with a dial-up internet connection and a pre-StackOverflow internet. That was hard, and I remember giving up many times when I got stuck, but somehow I always kept coming back and I often found solutions via div-arena.co.uk’s discussion forums. It taught me how to persevere more and how satisfying it could be to build something from scratch while solving all kinds of technical mysteries along the way.

I built a few more simple games, but eventually I kind of lost momentum and didn’t program much for a few years. It’s only when I was 19, while I was studying something not-so-programming-related, that I realized this is what I wanted to do.

Either way, I have a lot to thank DIV Games Studio for, because once I picked up programming again, it was a lot easier for me to get started.

The Software Muscle

If you apply small, but relatively frequent stress to a muscle, then over time it will adapt and grow stronger. We don’t frequently talk about it in the context of software development, but I believe it holds here too. By frequently applying small amounts of stress to our software and processes, we can greatly improve them over time.

If you look at the practices that exist today, you’ll find plenty that follow this principle. When doing continuous deployment, we deploy automatically on a frequent basis, often even on every commit to master. Each deployment applies a little bit of stress. And sometimes… things will break! But that danger is what helps us make our process more resilient. Would you rather deploy a huge change once a year, with the risk of a massive downtime that's hard to recover from? Or, do you deploy small changes, many times per day, with each potential issue helping you learn more about your deployment process? I know which one I prefer.

Of course, at first, switching to this flow can be pretty scary, and probably for a good reason. There are many things that can go wrong if you aren’t used to deploying that frequently. If you only workout once a year, you may get hurt if you’re careless. However, once you commit to moving towards more frequent deploys, you’ll learn to tackle these issues one by one. Note that you don’t have to deploy on every commit from day one, you could just deploy once per workday or per week initially. And, of course, depending on your context, there might be constraints which prevent you from reaching the “deploy-every-commit” state, but the principle still holds and it’s still valuable to deploy as frequently as you can afford.

I see another application of the principle of “software as a muscle” in services that automatically update your dependencies, like Dependabot or Depfu. These services watch your dependencies for new releases and then automatically make a pull request with an attached changelog. As a result, we end up with frequent and smaller dependency updates, instead of the semi-regular “Let’s update all the libraries and see what breaks”. Again, there are more frequent smaller stresses, and something may break occasionally, but this helps us improve over time. Our software stays up-to-date and will be more enjoyable to work with, given the more up-to-date dependencies.

Similarly, I see the idea at play in the Chaos Monkey tool built by Netflix. Quoting their README file:

Chaos Monkey randomly terminates virtual machine instances and containers that run inside of your production environment. Exposing engineers to failures more frequently incentivizes them to build resilient services.

Finally, I believe it’s also one of the principles that makes Test-Driven Development valuable. By adding tests to our code, we apply a bit of stress to it, which verifies that the code behaves as we expect it to. When we apply changes to the code in the future, those tests again will verify whether we are not breaking anything.

If you see any other places in software were this applies, please let me know! I’d love to hear from you.

Why aren't you doing one-on-ones?

It's hard for me to express how much I value one-on-ones, but I'll give it a go. It would be the last meeting I scratched if I were asked to remove all but one. I've even left a company once with the lack of one-on-ones, and their reluctance to implement them, being the primary reason. In my opinion, it was leading to numerous recurring, yet preventable, problems. A process-oriented meeting like the one-on-one would have been perfect for solving that.

So if they are truly so valuable, then why don’t more companies or managers do them? The excuse usually goes something like this: "One-on-ones take a lot of time, so we don't do them on a regular basis, but my door is always open."

"One-on-ones take a lot of time"

They do take up quite a bit of time, but it’s well-invested time that provides a long-lasting return on investment. Knowledge work is about both efficiency and effectiveness. A one-on-one of just 60 minutes can improve both that efficiency and effectiveness of a team member for the coming weeks. From that perspective, it's one of the most high-output meetings you can have.

One goal of the meeting is to address any existing or potential problems, which I’ll discuss a bit more below. Another is that to provide an opportunity for coaching. During the meeting, direct reports can get feedback on their performance, which will help them grow and reach their potential. Likewise, the manager can collect feedback on the processes, new ideas, their own performance, etc.

"My door is always open"

One-on-ones are intended to lower the barrier to discussing problems. You want issues to reach you early, so they can be addressed at a low-value stage and don't get a chance to grow into big monster catastrophes.

By saying "my door is always open," you are attaining the exact opposite goal. Now, people will have to convince themselves that the problem is big enough to be discussed first. Usually, this will prevent them from talking to their manager, even though their feedback was probably valuable. On top of that, whenever they do see someone talking to a manager one-on-one, they'll think that something is wrong. They'll also assume that their colleagues will find it suspicious if they are talking one-on-one with their manager and now have yet another reason to not talk. Compare that with, for example, a bi-weekly one-on-one. Now, there's a regular process for discussing any potential problems and there's no suspicion from others.

If done well, the one-on-one creates a safe environment where problems get tackled quickly. In good companies and teams, problems surface quickly so they can also be solved faster.