How does pair programming work?
We want to be responsible for our own successes and failures. That is why we need to take some decisions into our own hands. When we really know some things can be better, or how a thing will be better, we need to fight for it. Sometimes, we win, sometimes, we lose, but it's important to have an intellectual debate about how to use our time, what we should learn, and the options for the tools and technologies appropriate for the job.
Knowledge work and knowledge workers
Programmers deal with knowledge every day. They take some raw information, and they try to shape it into systems. This whole effort is not a simple one; it requires a lot of analysis power, abstract thinking, and discipline. It is always an endeavor of partial results, slow progress, frustration, and enjoyment.
Continuing this train of thought and using the concept of knowledge workers that we introduced previously, we can conclude that programmers are knowledge workers. And not only programmers, but everyone in any software development team is a knowledge worker. This view is essential when it comes to thinking about the activities that we need to perform in a software development team.
Learning is not optional when we're dealing with knowledge work. I often get this question: how can I convince my manager to let us learn X? If a software development team doesn't learn, they are doomed to create low-quality products, with high maintenance costs. Looking just at the momentary time costs of learning is a very narrow and unjust way of looking at this. We always need to look at both the short- and long-term benefits of whatever activity we set out to complete.
Use pair programming as a tool so that you become a knowledgeable knowledge worker, with the appetite to learn more, always improve, and strive for the best. Have pair programming sessions where you focus on optimizing your learning time for the vast amount of knowledge that might be right there, in your team.
Time well spent
I am sometimes lazy, and a pair drags me out of this comfort zone that I'm in. When pairing, you often feel a bit obliged to be there in terms of your full body and soul, so you don't have any phones, messages, chats, emails, or other side activities. In my personal experience, it is a good type of obligation – the one that gets me out of a state where I'm not very productive.
When in this state, I often feel really productive while pairing, compared to what I was doing just by myself. And that feeling is real and can be doubled by metrics. That is, if we count just the time spent versus the tasks that get completed, while forgetting about the better quality while pairing.
Often, I hear the following idea: how can two people work on the same task? It's absurd to lose the time of two people because you will produce just half the work! But things are more complicated than this, and not always 1+1 = 2, especially when we're dealing with people.
Think of pair programming as a catalyzer that makes the whole reaction a lot more effective. If we make the whole experience of pair programming a nice and attractive one, we will have larger benefits than if people were to work alone, by themselves.