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 need also to manage junior, inexperienced team members. How we deal with those who struggle is a strong reflection of our personality, and great test of how strong the team will be.

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 switch 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 a 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 very 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 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 just two weeks, is a huge 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 be a good mentor and truly help new employees become good team members.