There are always two sides to every story, and today, we’ll discuss pair programming from two perspectives: a senior developer (SD) and a junior developer (JD).
How do you divide up the responsibilities in pair programming?
SD: The best way is for a developer to drive — that is, to write the code and think out loud, with a secondary developer who takes notes and asks questions. The roles then reserve during the next session.
What expectations did you have going into pair-programming?
JD: I expected to learn from someone more experienced in order to build my skills and to better recognize my strengths and weakness so I could further progress.
SD: As an experienced developer, I thought pair programming would be a great way to share my skills with other developers. We value professional and personal development at Ekohe. This makes it possible for me to put in place a pedagogical discourse that could be easily understood by more junior profiles.
How did your actual experience with pair programming compare to your expectations?
JD: I wanted to improve my coding skills and to discover different approaches to solving problems, and pair programming allowed me to do that. What I like is being able to share with another developer my ideas and to hear others’ opinions about the code. Often, there are different ways of solving a problem and it’s easy to get stuck in a tunnel. Pair programming lets us open our minds to new ways of coding.
SD: After several pair programming experiences, I realized that some of my explanations were misunderstood. Most of the time, the problem came from my way of explaining an issue and my understanding of the subject. I recognized that the expression of “if you cannot explain something in one simple sentence, it’s because the answer is not clear in your head” applied to me and that I had to sometimes revisit the topic myself.
What difficulties did you encounter with pair programming?
JD: I didn’t really have any difficulties. I think it depends on the person. I would say that being patient and curious are the most important things to be successful in pair programming.
SD: I found it sometimes difficult to set aside the necessary time required for pair programming, especially during rush periods. It’s important not to postpone pair programming to a more “convenient” time. The truth is, pair programming is beneficial and even if it seems unnecessary, it could provide a multitude of advantages to the problems you’re trying to solve. With fewer distractions, productivity and efficiency do increase while pair programming.
This process requires patience. It’s important to understand the weaknesses of the junior developer and guide him or her along the right path without giving away the solution.
How often should people do pair programming. Should it be a regular, scheduled activity ?
SD: There are no rules, though people should definitely put pair programming on their schedule. I usually take 2 afternoons a week to do pair-programming. Personally, on Tuesday afternoons, I’ll go to the junior developer and comment on his work, acting as an observer. On Thursday afternoons, we reverse the roles and the junior dev will look over my code and act as the observer while I drive. The sessions last on average 1 ~ 2 hours.
When it feels like there’s no time to spare for pair-programming, I’ve found it helpful to drive and write the code while the junior developer observes and takes notes in parallel.
What do you enjoy about pair-programming?
JD: I like that I am able to learn a lot and see a new way of doing things. New possibilities open up and we get better at the code level. I’m able to approach things differently.
SD: Even as an experienced developer, we learn every day, even from developers with more junior profiles. Some of our explanations confirm our understanding and even open up our knowledge. The questions we are asked are random and unexpected, which leads us to reflect on new problems or to approach new methods. It’s a good exercise to adapt to different developers and complexity of questions.
What situations are best for pair-programming? Are there situations where pair-programming is not recommended?
JD: I don’t think there are any good or bad situations for pair-programming. You just have to do it whenever the junior or the senior finds it necessary. I personally think that it’s interesting to work with a senior dev at the start of a project. It helps to put in place good practices of which I otherwise may not have been aware. I can also get a deeper understanding of the chosen architecture logic with the help of the senior.
SD: It’s easier to do pair programming with developers who are working on the same project as you. As I said before, it’s important to do pair programming even during rush periods. It’s crucial to know how to synthesize your work in order to maximize efficiency and solve the problem at hand. Rush periods are ideal for learning this.
What suggestions do you have for people who do not enjoy pair-programming?
JD: I can’t imagine why someone wouldn’t enjoy pair programming, but I do think that we code faster as a team than when working alone. As long as both individuals are ready to exchange and help each other progress, there are benefits for both parties, not just for the junior developer.
SD: Code review is a good way to transfer skills. But some skills related to using tools (terminal, ide, etc.) and breaking down the logic of an idea are difficult to transmit online via chat; it’s always better to discuss these things in person.
Key Pair Programming Takeaways
- One developer acts as the driver (coder at the keyboard) while the other is the observer. Then you switch.
- Pair programming can benefit both senior and junior developer. Keep an open mind—be ready to learn and share what you know.
- There are no set rules on when/how often to pair program. Because we all have different ways of working, developers should adapt their pair programming session to their environment and way of processing. The important thing is to put aside time for it and don’t let other things take priority.
What are your thoughts and experiences with pair programming? Share them with us!
