Have you ever been working through a problem only to hit a roadblock that leaves you stuck, not knowing what to do next?
What did you do next?
Chances are, if you are like most programmers, you took a moment to check your Facebook, your email or perhaps your RSS feed.
If you sat down and really thought about what to do next you could probably have figured out at least one step and taken it, but let’s be honest with ourselves—most of the time it is easier to just switch tasks or take a break than it is to plow forward.
Human beings are procrastinators
And that is simply because we are modeled after nature.
Most things in nature take the path of least resistance; electricity, water flowing through pipes, you name it, nature is programmed to take the “easy” route.
Programmers are no different.
Now, I am not saying that we all procrastinate all the time. I’m not making excuses for it either. And, sure, you can overcome your procrastinating habits through focus and self-discipline, but it is not an easy road.
If you are a manager or lead others in this field, it is very important for you to understand this point, because it can help you to break structure work in such a way that the path of least resistance is to get the work done.
If you are an individual developer working on a project, or perhaps your own project, you need to know this as well, because just knowing this will help you to understand how to better structure your day and your time to mitigate the problem of procrastination.
Two are better than one
There are many reasons why pair programming works to increase productivity, but I’ve always held that the most important reason is because it prevents developers from procrastinating.
It is often a tough sell to management that two developers will start working on one computer. Surely sacrificing parallelization has to come at a high cost.
But, when you look at the honest truth of productivity, you find that around 40% or more developers only actually put in about 4 hours worth of real work a day on average.
The world just has too many distractions that equate to the path of least resistance.
Now let me ask you a question. When was the last time you checked your personal email or looked at your stock portfolio when your coworker was sitting at your computer, working on a problem with you?
Suddenly the path of least resistance has changed from seeing what clever thing has been posted on twitter by The Oatmeal to getting the work done.
There are a couple of reasons for this:
- The obvious one. It is impolite to cause your coworker to have twiddle his or her thumbs while you check your personal email.
- Working with someone else greatly decreases the chances of getting stuck.
Remember getting stuck is our big problem. I sincerely believe most developers want to do a good job, not just for their employers, but for themselves as well.
The big problem is when I get stuck, I tend to be like a stream hitting a dam, I just divert and go another direction, (whichever one is easiest.) Now, I manage this weakness of mine in my own way by breaking things up small in order to make those small things become the path of least resistance, but the best thing by far is to have another developer that is smarter than I am sitting next to me or remoted into my machine, who isn’t going to get stuck and helps us plow forward.
Now, I realize this might not apply to you. You might be a super programmer who spends all 8 hours of his or her work day writing perfect code and never getting stuck, and pairing up with a mere mortal just slows you down, but if you are like me you need all the help you can get.
It’s not just pair programming
When I say pairing, I am not just talking about pair programming.
Do you have to have two developers sitting at the same workstation all day long?
No, I do think you should definitely do some of that, but I don’t think it is essential to be constantly pair programming.
What I do think is essential is to have at least two developers working on a single problem at the same time.
It provides some accountability that goes a long way towards making sure work has some progression and it will prevent developers from getting stuck, because they always have someone to bounce ideas off of who is facing the same problem they are and is just as responsible for the delivery of the solution.
If possible it is best to have the whole team involved as much as possible with every backlog, but I realize this is not always possible.
The key thing is that work always progresses, because it is much harder to get stuck if you have two people committed to the same objective. That doesn’t mean that a team can never get stuck, but it is much less likely. Besides, if two or more people are stuck on a problem, it is a good indication that you may be facing a really hard problem or more likely there is something else wrong with your development process that is causing your teams to get stuck.
If one developer is stuck, it might just be because of a weakness in their abilities, but you can almost always count on two or more developers being stuck as a sign of something else.
So, while pair programming is definitely beneficial, it is more essential to have more than one person assigned to a single objective. The real benefit lies in the sharing of fate.
Don’t forget personal time
So, now that I’ve convinced you that pairing up is good and will reduce that procrastination factor, you’re going to rearrange your team and make sure everyone is always working together all day long, right?
Wrong!
Don’t forget that humans are still humans and have lives and priorities that extend beyond their jobs.
It is really important for developers to have time during the day to check their emails, return calls from the school principal, and to just stop for a moment and decompress by reading a news article.
Sometimes the most important revelations come to us when we are taking a break or goofing off.
If you are reading this post as a developer looking to up your productivity, the same applies to you—don’t get carried away.
I’ve seen all kinds of intricate tools to measure how much time you spend doing what throughout the day with stop watch precision, and while there are some benefits to using a tool like this to see how you are spending your time, the pressure of fighting so heavily against your nature is likely to result in a complete abandonment of any kind of time management practice. Time management anarchy!
If you practice pair programming in an environment such as eXtreme Programming, you have to be even more careful to make sure you are scheduling non-pair time to take care of work things like email and self-organization, as well as personal things mentioned above.
I’ve seen many environments where pair programming is supposed to be fun and productive, turn into a sweatshop factory where developers resent not having some space to themselves. (This is one the biggest fears I have found that causes resistance to pair programming in general.)
Reference: Avoiding Procrastination Through Pairing from our NGC partner John Sonmez at the Making the Complex Simple blog.
