Be a good mentor, not a dickhead

I’ve worked with a lot of people of varying skill levels, from superstar programmers to not-sure-how-they-got-the-job types. Integrating and working with new people is always a daunting task. For great people, it’s obviously easier, but we also need to manage junior, inexperienced team members. How we deal with those who struggle is a strong reflection of our personality and a good test of how strong the team will be.

In my book I talk about new team members and also taking care of yourself at work. It reinforces why it’s important to be a good mentor.

Avoid the write-off

Jill shows up to her first day on Monday. We give her a computer, show the coffee machine, some source code, and then point her at the issue system. She sits there quietly, and then asks, “what’s an issue system?” Odd, but okay, we explain it to her, show her some basics. We give her an issue and tell which code she needs to checkout. We come back an hour later, and Jill’s still struggling to get a basic git command to work. We help her out and then point out a few key Python files. Later in the day we look over her shoulder and see her searching for basic Python syntax.

So goes the first week, or two. What’s going on? Does Jill know anything? How did she get hired and put on my team!

There are many reasons why Jill could be struggling. It’s best to consider the obvious ones first. It’s a new job, that alone is a stressful situation. While some of us switch jobs as often as we change buses, most people keep their positions for many years. Some are just coming out of school. Taking a new job means a lot of new things in life, not just new work. So let’s go easy on Jill and maybe not push so hard at first.

The technology is all different. I’ve never encountered a company that used the same tools and setup as one of my previous positions. At best I’ve seen only one or two tools I used before. We tend to forget how much time we’ve invested in learning them already. We know that “WirlyCritterz” is the issue system, but how would a new employee? Chances are little of our system is written down, or the docs are sorely outdated.

We have to avoid letting the stress of all this novelty give us a negative impression of Jill. A few people can jump in and be productive the first day, but my experience shows that even great programmers can take weeks to get their footing in a new situation. The more we help the people in this time the better they will view us, and the company. If we don’t take the time, we’ll have given a very negative impression that can stick with Jill so long as she works with us.

I find it best to completely ignore people’s experience at this time. I try to treat every question they have as a valid and insightful question. Sometimes I just don’t know their background; I may not have been on the hiring team. Often I’m unaware of what nonsense the recruiter has told them about the company*. Maybe I just need to get used to a new accent. Maybe they I just need to calm their anxiety and think clearly.

*Please, for all recruiters and HR staff, stop lying to candidates about the position and company. It makes it really hard to integrate a new member if the project they start on seems tangent to the one they’ve been described.

Okay, but what about Tom?

Great, after a few weeks Jill has integrated well and is on the path to being productive. But Tom, who started at the same time, just doesn’t seem to be making any progress. He’s still struggling with the issue system, seems to screw up git merging all the time, and is producing awful code. He’s on the path to disaster.

We have a decision to make at this point. Either we commit to helping Tom, or we fire him right now. If we start ignoring him the problem just gets worse, he gets bitter, and everybody is unhappy. Deciding to fire him now, after only two weeks, is a substantial negative reflection of ourselves and the company. I can’t imagine the hiring process going so poorly that I’d get a mismatch this bad.

I’m not saying the hiring process can’t go completely askew. Total mismatches sometimes happen. But it’s generally only after working with somebody closely for a month or so that I can be certain of it.

The difficulty now is figuring out what the problem with Tom really is. As much as possible I’d recommend reducing his workload. Not just his actual workload, but his perceived workload. If we give somebody a list of 100 issues, they can feel overwhelmed by that alone. Let’s make sure Tom realizes he can safely work on just one issue, and take as long as he needs.

We’ll need to give ourselves time to help Tom. When he has questions, we need to answer them fully. Being attentive while answering also helps us understand where the communication gap is coming. We can’t just throw him some docs either. Let’s show him how we’d solve the problem using those docs — we might discover many issues with the docs themselves this way.

It’ll be necessary to review Tom’s work as well. Let’s not just call it rubbish or tell him to clean it up. We need to give specific constructive feedback on how he can improve the code. Giving the varying quality of programming education, and numerous examples of questionable code online, it should almost be expected that junior programmers write crappy code. If somebody doesn’t help them now, they’ll end up writing crappy code their whole career. Nobody wants that.

Finding out what Tom enjoys is also helpful. Getting upset with Tom for his lack of interest is rarely productive. It would be better to find out what part of the project he feels most comfortable with. As long as we can find something suitable, then Tom can become a productive member of the team.

Patience and time

It’s a struggle to integrate new employees. We hire people because we’re overloaded, thus making it hard to find the time for the new people. Some people require less assistance, and that’s great, but others need a lot of help getting on track. We shouldn’t be hiring if we’re unwilling to spend the time making it work.

It’s tempting to assign difficulties on the new hire themselves: a limitation of their ability or their drive. Even if it is, who cares? Not helping the person virtually guarantees failure and then we have to start the hiring cycle again — something which takes a lot of time. Plus, firing somebody can leave an awful feeling, especially if we’re not positive about it.

It’s in our best interest to be a good mentor and truly help new employees become good team members.

Categories: Editorial, Management

Tagged as: , , ,

5 replies »

  1. Agreed completely. I ramp up relatively quickly these days – but that’s only because I’ve been through the process many times. I was in Jill’s position or even Tom’s position many times.

  2. I would say this sounds pretty normal and reasonable. However, I’d also review the person’s resume. It they claim to have expertise that clearly doesn’t exist in practice, that’s a huge red flag.

  3. I hate to say so but this is where a very small very simple C/C++ test case help in an interview, not one filled with truly difficult questions, but one which anyone who’s done more than 2 weeks of continuous coding could do in their sleep. I found even the simple examples weeded out those people who are not being 100% truthful on their resume.

    Every developers first bug fix should be a spelling mistake! As your first task should be to learn how to checkout, rebuild and commit, not change the a fundamental algorithm. It also gives a very immediate sense of actually contributing to the greater good of next release for the new starter and makes them feel part of the team!

    To the untrained candidate who wants a job in development, make sure you’ve gone onto you tube, download a free compiler and spend a couple of weekends learning how to code a very simple task!

    • I can’t really argue with what you’re saying, but I do have an anecdote. Shortly after the birth of our second child, I got laid off. I was desperate to got back to work, and it showed in my interviews. I botched dead simple questions like “How do you know if a string is terminated in C?” and generally came across as a moron. After I got a new job and worked there for a year, I interviewed at a second place and aced the questions. I was offered twice my then-current salary. Of course the difference was that I already had a job and there was no pressure on me if I failed.

      Again, I still think it’s a bad idea to hire someone who can’t even start a solution to FizzBuzz or whatever. Without telepathy, you can’t tell if they’re blocked by nerves or incompetence. But I wanted to throw that story out.

  4. Recently started at a company as a summer intern and I feel like I’m in Tom’s situation. Luckily I’ve actually accomplished some things and finished my first task.

    The most difficult part seems to be to understand the system on both a system-wide level as well as a modular level. It really helps having a mentor who is there for all your questions.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s