Advertisements
Posted by: jsonmez | September 3, 2012

Avoiding Procrastination Through Pairing

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?MC900071181

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.

MH900071008

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:

  1. The obvious one.  It is impolite to cause your coworker to have twiddle his or her thumbs while you check your personal email.
  2. 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.

MH900386250

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.)

Advertisements

Responses

  1. I dont want to keep repeating myself, but this is the second and last time, i really love your blog posts and i haven’t been reading and following so closely a blog before as yours. It keep me on track and motivated some way, because as i have mentioned before, you write about development from a bigger perspective. Keep these blog posts coming! 🙂

    • Thanks, appreciate the comments 🙂

  2. If you work alone on a project I think your advice to break up problem into smaller pieces is very good. If you start doing this, then you’ve started thinking deeply about the problem and working on it already.

    • Yep, I agree. I was procrastinating on the post until I sat down and said. Ok, just figure out your topic. Then write the opening section.

  3. Good explanation and I am impressed with the way you explain or promote pair programming. As you mentioned, the biggest worry is privacy or personal time. Like you suggested, should we start pairing whenever someone is stuck in a problem and he calls certain experts? Or start attending a problem from the beginning in pairs?
    Also if I have to suggest this over regular work, I do not see pair programming any different than what we do today. When I am stuck in a problem, I mostly Google! it. (Pairing with Google) or ask one of my colleague who I think is an expert or worked on that problem earlier (Pairing with Colleagues) or call my friend to ask that problem if he knows the answer.

    Or Did my understanding about pair programming go any wrong?

    • Thanks! The only issue with pairing with Google or asking an expert is that they don’t have anything at stake. I find that when two people have a common goal and common accountability, they are more likely to be pragmatic in solving a problem.

  4. What an excellent and down to earth approach to go ahead in life.

    Thanks John.

    Regards,
    Adil

  5. Really good perspective on pairing. There’s a lot of resistance to this in most places, I hope to get pairing going at my company – not easy. Great post!


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Categories

%d bloggers like this: