Have you ever wondered what Pair Programming is, or how it works? “If I were to summarize Pair Programming in four words, it would be ‘Two programmers, one pencil.’
One day I was just listening to a tech podcast about software development techniques and heard about Pair Programming. When I joined Forbes, I introduced this practice to my team. I think it’s a common misconception that software development is a solitary field. Rather, teamwork or collaboration is a key element in software development projects.
I went out on maternity leave.
It was a fantastic period as a mother. But, my developer hormones were continuously pushing me to start my job as soon as possible and catch up faster with a team.
Here comes the point where the pair programming felt like bliss, so I messaged Pete as he had some knowledge with unit tests at that time, to walk me through the project.
Seven weeks into my summer internship at Forbes Media, Anastasiia sent me a Slack message about working on her first unit-test ticket. I had merged about a handful of unit-test pull requests at this point, but that development (and struggle!) was done in isolation. No one had to watch as I stared blankly at error messages for (what seemed like) hours on end.
Fortunately, I had a little bit of time to prepare. Something my mentor previously said struck me at that moment. “Look for patterns in the code…”
Before we met up to work on the unit-test, I looked over the component in question and tried to assess its complexity and functionality. Then found similar components that had already had unit-tests written. Armed with a couple of unit-test examples, we connected and I started by screen sharing my code editor.
[Anastasiia’s perspective, Google Meet]
Pete and I connected, we reviewed some unit-test examples, and discussed the imports. Next, we reviewed rendering a component, then challenging it with an assertion. Afterwards, we ran the tests to have a visual example of passing results.
Next step was to modify the unit-test so that it fails. Failing the test would render the component code to the console and make it a little bit easier to see what the unit-test is actually rendering. After this, we decided to start the development for the unit-test ticket.
Since I was ‘driving’ I reverted to my natural development habits… A few minutes into this, I realize that I’m talking to myself as I code (this helps me keep some of the abstract logic straight). It’s part of what I naturally tend to do, but now someone is listening to me!
Turns out this was helpful as it was a bit easier to follow my thought process since I was being more vocal.
Finally, we touch on code coverage. We discuss accessing the report, as well as interpreting the results. At that point, Anastasiia (with an excited tone in her voice) had enough!
She sounded comfortable and wanted to try it from scratch, on her own, or maybe she was just tired of listening to me talk to myself.
[Anastasiia and Pete] Perks of Pair Programming:
Fewer Bugs and Quality Code – Two developers quickly correct each other’s mistakes and use shared knowledge to solve problems faster. Two sets of eyes can see more problems than one; both have different ways to identify the problem.
Faster Training – In pair programming, the collaborators are usually both experienced or one expert and one novice. It is a huge perk for the juniors to learn quicker and for the company to speed up the onboarding process.
Increases teamwork and team communication – Last but not least, one of the amazing benefits of practicing pair programming is increased team communication and building opportunities. While doing the pairing, developers inform each other more about their work and trust each other. It helps build better relationships with other colleagues.
Even in remote pairing, teams work together and interact in different time zones and locations. And we believe that building and strengthening work relationships are essential for any successful agile team.
Wrapping up – If you’ve ever heard that ‘two minds are better than one’, it is pretty true in the context of software engineering.