New hires are an opportunity to reevaluate

Your company’s development team is fairly stable. It’s the same people working together every day. That stability makes for great things: it improves the quality of team work, makes for more constructive feedback, and builds a shared vision for what the code base should look like.

Hopefully the stability doesn’t mean that you aren’t trying new things. Hopefully you are still evaluating new technologies, reevaluating past choices, and figuring out new ways to approach design that might be a benefit to the readability and extendability of your code.

Then you hire someone new.

That brings with it a lot of things. You will spend a lot of time bringing the new developer up to speed, transferring knowledge from the team to the new member, teaching them to develop the way you develop and how the code base works. So they can pull their weight.

It probably also leads to the new developer asking some questions: what does this thing do, how should I approach this problem, what does this term mean?

Sometimes these questions are natural parts of the learning process. Questions the new member just needs answers to.

Sometimes they are an indication that you can improve something, use clearer terms, or make something just a tiny bit easier to understand.

With a new hire you have the opportunity to see things from a different perspective. Not just because they don’t know your system and are seeing it for the first time, but because they come from somewhere else, with different experiences and knowledge.

Maybe they know a neat trick to get around something you have been struggling with.

Maybe they have previously solved an architectural problem that you didn’t even know you had, but that they spot right off the bat.

This is an opportunity to listen and learn new things, see things from a perspective that you have not yet seen them from.

But it’s very easy to miss this opportunity when you’re on a mission to impart knowledge. All these questions are distracting from the main goal, bringing the developer up to speed. But maybe they are useful distractions.

In all interactions with new hires, watch out for things you can improve. When they express doubt, ask them what they would expect the answer to their question to be, then figure out why the discrepancy exists.

Use this opportunity to make onboarding the next team member even easier.

I write stuff on a pretty regular basis, but not on a schedule. Keep up with when it happens by subscribing to my newsletter.