Some time ago I wrote how pair programming can help keep high quality of the code. But that’s not all!
Today I want to explain why you should practice pair programming to onboard a new joiner. It makes the whole process faster and more efficient.
New joiner joins the team
In most projects I was working on we assumed that a new joiner would have a negative impact on the team’s productivity for about three first months. That you have to help them settle down in their new job and help them set up everything. That you have to share all those tiny little hacks in your projects and your tools’ configuration.
There will be questions. And they will expect an answer for each and every of them. They will bring ideas, suggestions, comments. There will be a lot of “whys” during these days. And that’s good! That confirms that letting them join the team was a good choice.
But those are three months! Three long and exhausting months. For both parties – the team and the new joiner. And the bigger project, the longer and more exhausting this time can be. During my career I saw a few ways of onboarding a new joiner. Let me challenge those I found most common.
Let’s solve a bug
The idea is to give a new joiner an opportunity to learn the application by looking into a juicy bug. They will have an opportunity to see and learn everything, wouldn’t they?
However, even if you really believe it works there are a few problems with this approach.
New joiners understand neither a business domain nor technical aspects of the application. It’s obvious, but in comparison to introducing a new feature, the lack of knowledge in this case makes things significantly harder. They will ask, obviously, but first steps are usually attempts to understand everything on their own. Next steps lead them to Google. And then, on the far end, will be questions. So it will take time, a lot of it.
You also have to remember that when solving a bug, there’s a chance they will land in some forgotten places. They will see code no one can understand anymore. They will ask questions no one has answers to in their heads anymore. It will require some effort to find them.
What is also important to have in mind? A new joiner may end up struggling without clue where to go, lost in the code, with small chances for a success. Doesn’t that sound demotivating? What do you think?
Going through the code
“Just go through the code and ask as many questions as you want. You may start here, here and here.”
– I said it myself a few times in the past. What was the effect? Hours of googling and tons of questions. On the face of it, it can even look good, but the problem is that a new joiner asks and learns also about things/modules/places which are almost never touched.
The goal in onboarding is to change new application into something comfortable to work with. Not to fill the new joiner’s head with every possible detail.
Knowledge sharing sessions/documentation
It’s great if there’s documentation for your application. It’s great if you are organizing knowledge sharing sessions. But it can work only as a fulfillment for other activities, not as a replacement.
Even if you provide a detailed session and have got rich and up-to-date documentation, it is impossible to remember all the things. Even if someone is eager to learn, there’s small chance they will remember more than a few percent.
Just start working
At least new joiner knows they’re doing something important, something users are waiting for. In case of question most of people in the team will be able to provide an answer – they are already in the same context.
There’s only one “but” – continuous interruptions. There will be questions and one of you will have to provide answers or show the right direction. It has got negative impact on both new joiner’s and your work. Why?
The more questions, the less comfortable a new joiner may feel with asking next one. They will try harder and harder to find an answer on their own.
On the other hand, in case of questions you will have to stop, you have to change the contexts and it has a price.
This slows both of you down.
Pair programming for the rescue!
For some time I thought letting a new joiner start working on our current deliverables is the best choice. Yet, interruptions still were the problem. Questions are a constant during onboarding and you cannot eliminate it.
What can you do instead? You can eliminate negative impact they bring if you have to interrupt other’s person work to ask them. If you pair, then you eliminate those interruptions completely! You are working on the same thing so you are in the same context. Questions are within the same context!
Additionally, by looking at the way how you are writing code new joiner becomes more familiar with techniques practiced in your team. By looking at them you can share a feedback without waiting for questions.
A win-win situation, isn’t it?
Next time, when someone new joins your team, I encourage you to try to pair with them. I’m pretty sure you will find it as an efficient and fast way to onboard a new developer! Good luck!
| Reference: | Pair Programming to the rescue once again! from our JCG partner Sebastian Malaca at the Let’s talk about Java blog. |
