I’ve heard managers say that they want someone who can “hit the ground running” far too often. The problem is that literally nobody hits the ground running.

What managers really mean when they have this attitude is that they want a replacement for $FormerEmployee because they think that the people that work for them are “fungible resources.”

You can’t know everything day one. And, honestly, you shouldn’t have to.

At “best,” you find someone who has worked with every technology that you use (good luck with that). Even then, you have to do onboarding, get the development environment set up, and spend time for the person in question to learn their way around your codebase. All of this takes time.

Before you try to strike “onboarding” from that list, I’ve known multiple places where the time it has taken to get every piece of software, access, etc that an employee needs has been measured in months. (yes, really). There are a number of causes of this, but they can and do happen (far more often than you’d believe, honestly).

I once had to fight for a couple of months with the cybersecurity team at a Fortune 100 company in order to get access to a secure, externally accessible file share in order to collaborate with one of our vendors for a new product that we were piloting/building with them (and that was after we went through the hassle of getting everyone involved to sign the required NDAs and other paperwork. Legal was okay with it, but not the infosec people, and most of the information being given to the vendor was literally logs for their own product). No joke.

In the more realistic (and, in my opinion, better) scenario, you also spend time for the person to ramp up on at least a couple of technologies that you use which they don’t have any real experience in.

Why is having someone spend time ramping up on new technologies a better thing? As software developers, we are constantly learning and growing. If we aren’t learning, we’re effectively falling behind.

If you hire someone who has nothing to learn at your company, the chances are that they aren’t going to stay around for very long at all. Additionally, you’re probably going to have to pay an extreme premium to check all of your “requirement” list.

All of this is in addition to the time spent finding their place socially in your team and organization. That in itself is not always a trivial task.

Now that I’ve said that, I will admit that there is a way to have a new team member be productive within the first few days, but the type of manager who wants people to “hit the ground running” is probably going to balk at it because they would likely view it as wasteful.

The answer is pair programming.

Pairing is, in my experience, probably the easiest way to not only familiarize a new team member with your codebase but with your organization. It helps socialize them to the rest of the group, helps them gain institutional knowledge, and a number of other things. It even helps the existing members of your team learn things from the new person.

You still don’t “hit the ground running,” but part of your orientation into the new company involves actively working with someone who can help decrease your ramp-up time.

The typical argument against pairing is that you’re paying two people to do the job of one person. The truth of it is that you’re probably going to get the “output” of about one and a half people, but it will be of a higher quality from a maintainability standpoint and you will have more than one person who is familiar with the code in question in case someone goes on vacation or leaves your company.

The reasonable alternative is to realize that a new person is going to take time to be truly productive, and that this is normal. People aren’t replaceable cogs and we really need to stop thinking of them that way.

The unreasonable alternative is to expect them to “hit the ground running” and to be upset or angry when they don’t meet unrealistic expectations of productivity.

The first two options are far better from a quality of life standpoint for your organization and its employees. If you go with option three, your turnover is likely to be much higher, your people won’t care about their jobs nearly as much.

Life and business are a series of tradeoffs. Make your choices carefully.