Pair Programming to the Rescue Once Again!
Pair Programming to the Rescue Once Again!
You've hired a new dev, and they have a lot of questions. That's good. But what happens when this interferes with work? Pair programming helps ease the transition.
Join the DZone community and get the full member experience.Join For Free
Discover how TDM Is Essential To Achieving Quality At Speed For Agile, DevOps, And Continuous Delivery. Brought to you in partnership with CA Technologies.
Some time ago I wrote how pair programming can help keep code high quality. 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 Developer 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 the first three 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 one 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've seen a few ways of onboarding a new joiner. Here are the ones I've found to be the 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 the business domain nor the 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 questions, obviously, but their first steps usually attempts to understand everything on their own. Their next steps lead them to Google. And then, on the far end, will be the 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. It is also important to keep in mind that a new joiner may end up struggling without a clue as to where to go, lost in the code, with little chance of 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 also asks and learns about things/modules/places which are almost never touched. The goal in onboarding is to change a 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 only augment other activities, not fully replace them. Even if you provide a detailed session and have got rich and up-to-date documentation, it is impossible to remember everything. Even if someone is eager to learn, there’s a small chance they will remember more than 10% of the information thrown at them.
Just Start Working
At least the new joiner knows they’re doing something important, something users are waiting for. In case they have questions, most of the 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 will have a negative impact on both new joiner’s work and your own. Why? The more questions the have, the less comfortable a new joiner may feel with asking the next one. They will try harder and harder to find an answer on their own. On the other hand, you will have to stop what you're doing to answer their questions. This slows both of you down.
Pair Programming to the Rescue!
For some time, I thought allowing a new joiner start working on our current deliverables was the best choice. Yet interruptions were still a problem. Questions are a constant during onboarding and you cannot eliminate it. What can you do instead? You can eliminate the negative impact of having to interrupt another person’s 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 you are writing code, the new joiner becomes more familiar with the techniques practiced in your team. By looking at them you can share 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 an efficient and fast way to onboard a new developer! Good luck!
Published at DZone with permission of Sebastian Malaca , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.