Pair programming is nothing new and has already got many followers. There are also opponents who claim that there is actually no need for anything. What is the reason for introducing this method of work in the company?
Pair programming is one of the extreme programming practices (eXtreme Programming, XP), which is increasingly considered to be agile software development methods. Encoding in pairs from the beginning fascinates researchers. As early as 1998, John Noska conducted an experiment that found that couples needed 30% less time to write code than a single programmer, but the workload of programming in pairs was 40% greater. A few years later, Laurie Williams of North Carolina State University published a study showing that labor consumption is only 20% higher than that of a single programmer, and that software is 40% faster. In yet another study, software that was created in pairs has 15% fewer errors, and 95% of the working developers are more sure than their own. Apparently, pair programming has its advantages, but for the first few words of explanation.
How it's working?
The Mythical Man Month, Fred Brooks, programmed this way in college in the 1950s. In 1992, Larry Constantine described the Dynamic Duo, which was used in the late 1980s at Whitesmiths: one computer programmer wrote on a keyboard and the other looked at the monitor. Three years later, Jim Coplien discussed programming in pairs in one of the chapters in the Pattern Languages of Design program. In 2000, Sallyann Bryant introduced the navigator and driver names in the article Pair programming and the mysterious role of the navigator. Two years later, Pair Programming Illuminated Laurie Williams and Robert Kessler appeared, and in 2015 James Coplien released Two Heads Are Better Than One on the idea of programming in pairs to describe how it all started.
Pair programming is nothing but the joint work of two programmers. One of them is the driver, who is the main coder, is typing code lines and the other is a navigator. Its task is to observe the resulting code, catch errors, ask questions, and propose your own solutions. Every few dozen programmers change roles. This duo works on one computer. What gives this way of software development?
Advantages of programming in pairs
Pair programming is no extravagant or crazy experiment. This way of working has many advantages:
- Eliminate stupid mistakes that can be very annoying. Two people have a chance to catch them faster with a navigator, who should especially be careful of even minor mistakes. This allows you to create better software.
- New look at the problem. Sometimes there is a difficulty in encoding, which stops all work, and the search for a solution is over. Looking at the code on the side, the navigator can fall for a faster solution than the driver.
- Freedom while coding. We feel more confident knowing that we are a good person. In such a tandem you can fluently exchange knowledge.
- Pair programming is also a great opportunity to develop communication skills, develop good interpersonal skills, and thus acquire new soft skills.
- Saves time - the above-mentioned tests confirm that the software is faster.
- Saving money - shorter working time and fewer mistakes are less money spent.
- Improved teamwork - pair work undoubtedly fosters contact.
- Building trust between collaborating developers.
Mentoring for the encoder
Pair programming can also be considered as a mentoring technique. This is an ideal solution when it comes to teaching young adepts programming by experienced coders. A person who wants to gain knowledge is sitting at the keyboard and acting as a driver, mentor is a navigator. The driver has to look for a solution on his own and the mentor's role is to give tips and examples. Occasionally a mentor can take over a keyboard, write a piece of code, analyze it and explain it, but do not overdo it. The driver should look for the solution itself using hints. Pair programming can speed up the transfer of knowledge and also facilitate the deployment of new employees.
Recruitment
Pair programming is sometimes also used in the recruitment process. This is one way to test candidate skills. The person looking for a job is paired with an experienced programmer, they sit with one computer. The candidate receives a programming assignment for the solution, while the recruiter recruits his expertise in programming, the use of specific tools and technologies. This allows you to quickly and thoroughly assess whether the candidate has sufficient knowledge. This way, you can get more information than a technical skill test. The recruiter will be able to assess how the candidate can communicate, whether he or she is ready to ask for feedback, or whether he or she can take the initiative at work.
Pair programming for everyone?
Of course, it would be naive to think that programming in pairs is for everyone. It is not for simple reasons: not everyone is able to overcome the intimate barrier. It is assumed that the space around us at a distance of up to 45 cm. This intimate space is usually reserved for the closest family, family, children. Violation of this zone by a colleague of work can lead to discomfort and even cause various types of defensive reactions. It's pretty natural. Pair programming is an obvious example of such a breach of the intimate zone. For some developers this is a big problem and they can not find a way to do so, not to mention productive work. Therefore, pair programming is best when team members have strong relationships, friends, or at least very good friends and trust each other.
Unfortunately, this is not always the case. Therefore, it is worth building trust in the team also in the context of programming in pairs, prepare for this mentally programmers. Persons working in pairs must be engaged, focused on the work, not on thinking "Someone peeps over my shoulder, controls me." Then programming in pairs does not make sense.