Chapter 1: Pair Programming and Its Necessity
Pair programming can be easy to use when you are focusing on building software that is of high quality. You, as a programmer, can pair with other programmers to find quicker solutions to your problems and get better results. Furthermore, you can pair with other colleagues: testers, analysts, (dev)ops, security, and so on.
Pair programming in itself is simple: you have a driver who writes the code and a navigator who oversees the code. The two are roles that can change slower or faster, depending on your context. We will learn about them in more detail as this book progresses.
You can use pair programming in many moments. Typically, we pair program naturally when we are stuck and ask for a colleague's help. Also, we can schedule pairing sessions as a regular activity. Some like to pair daily, or just a few times per week. It's a matter of context and where it helps you get better results.
Usually, you pair program in the office, at your desk, or at your colleague's desk. You can take your laptop(s) and pair in a meeting room on a big screen, or on a terrace when the weather's nice. Or, you can remote pair program by using specific tools to pair with people wherever in the world, as long as they have good internet.
Continuous learning, improved quality, fewer defects, managing complex problems, and solving specific problems faster are just a few reasons to use pair programming. Because programmers deal with a mass of knowledge, wrapping your head around all the essential details with another colleague helps your endeavor with speed and quality.
In this chapter, we will cover the following topics:
- The history of pair programming
- Elucidating problems in pairs
- Sharpening knowledge with collaboration
- Gaining wisdom
- Managing complexities in complex domains
- Comfort for the future you
- Programming with your CEO
- How does pair programming work?
The history of pair programming
Pair programming has been around for a long time in the history of software development, even from the early days, when programming meant plugging in some wires into a control dashboard or inserting punch cards into a reader in order to compile your program.
It's just that people who used to program back in the day didn't call it pair programming; they called it simple, plain programming. You needed to do things in pairs because of the wires or the cards that were cumbersome to use.
Then came the era of industrial programming where, little by little, pushed by the need for automatization and computers being more affordable, programmers were working more and more alone. It was an age of simpler programs, but it took a long time to write, compile, check, fix, improve, write, compile, and so on.
After a while, computers started becoming more powerful and even more affordable. So, companies started automating more complex parts of their business flows. We are talking about financial systems, travel, trade, and so on. You had a complex domain already, but programmers were working alone, as in any other factory. They had a boss, like in any other factory, and a manager, like in any other factory.
The only problem with comparing factory workers with programmers is that programmers need to solve problems that are from non-routine work, while factory workers had a clear routine that might have been subject to change every once in a while. That is the moment when the concept of the knowledge worker appeared in the management literature:
"Every knowledge worker in a modern organization is an "executive" if, by virtue of his position or knowledge, he is responsible for a contribution that materially affects the capacity of the organization to perform and to obtain results."
- Peter Drucker in The Effective Executive (1966)
Pair programming then reappeared in some areas, and younger programmers read about the older ways of programming. They started using it with great success, and it felt very natural to have two people coding for a task. Plain pair programming is a simple system of managing complexity and gaining better results.
Elucidating problems in pairs
The best way of explaining why pair programming works is that two people can understand how to write some code better than just one programmer. It is true that when we code trivial parts of the system, pair programming is unnecessary – even counterproductive. So, it's important to choose when to pair program and when to solo program.
Here are a few situations where pair programming works great, and where the two heads are better than one rule applies:
- A junior programmer learning from a senior programmer.
- A new programmer in a team learns from an existing programmer in the team.
- Fresh tasks are assigned to the team, and two people can tackle the problem better and faster.
- A programmer learns new practice (that is, test-driven development, unit testing, and so on).
As a rule of thumb, it is a good idea to use pair programming when we have a task with higher complexity, either the technical or the business side. It's good to acknowledge that programmers are more likely to make mistakes in complex or unknown areas of code.
There are situations where we'll have simple, trivial tasks that don't necessarily need pairing, or even more, where pairing would be just a waste of time for at least one of the two. Often, it's a good idea to have this discussion with the whole team. After all, it should be the decision for the whole team on how they use their common time, what the learning or improvement focus is in the next period, and where they can't afford pairing because they need to deliver faster.
Should I pair? Before you start a new task, ask yourself the following questions:
- How would I benefit from using pair programming?
- How would the team/product benefit from using pair programming?
- Would we learn anything useful for the team by pairing?
- Would pair programming delay a delivery?
- Would pairing on this task be boring or superfluous?
These questions could help you and your team decide if it's worth investing in pair programming for that specific task. Yes, it is an investment, and you should treat every decision with objectivity and respect for the rest of the team. After all, two heads are better than one in some situations, though in other situations, where even one head wouldn't be used too much, using pair programming would just be a waste of time and energy.
Managing complexity
Following the idea that two heads are better than one, we can use pair programming to manage better complexity.
Let's face it: programmers almost never do the exact same task. It might be that the domain is similar, or identical, but there are so many moving parts in the whole ecosystem, such as programming language, frameworks, external or internal use libraries, programming patterns, architecture patterns, business domain variations, performance, security, scalability, and so on. A programmer needs to think about all these and more when writing code. That is why we can make a strong case when we say complexity is inherent in most programming tasks.
Having two people who look at all the aspects of the code is clearly beneficial. There is a driver who writes the code and a navigator who oversees the code, thinks about possible next steps, thinks about possible caveats, and improves the code while it is being written.
Humans only have one brain, and we can only focus our full attention on one thing. We can pivot our focus from one aspect to another, but that is tiring and during the switch, we might lose some details. That is why the driver focuses on writing the code while looking at low-level details such as code syntax, code logic, framework/library usage, or code formatting. And, at the same time, the navigator focuses on high-level details such as design aspects, architecture concerns, performance, security, and so on.
After all, what pair programming does is split the overall complexity into smaller, less complex parts that are easier to manage. These smaller parts are managed by two people, who use the clear responsibilities that are attributed to the driver and the navigator.
A good guideline is necessary for clarifying the driver and navigator roles before starting the pair programming ...
