trevmex's tumblings

JavaScripter, Rubyist, Functional Programmer, Agile Practitioner.

 ()

The Best Resume Builder: Pair Programming

BarCamp Session 2

Aaron Feng

Check out “The Art of Agile Developent” for good info on pair programming.

"You can do waterfall and still pair" -Aaron (don't be afriad!)

Pair Programming isn’t anything new, but it might not be what you are thinking about.

The end goal of pairing is to produce something that is high quality and do it effenciently. (eliminate your QA team)

Pair programming is not onecoder and one kibitzer. It is different than that. The idea is that two can be better than one.

We are coder, we are not factory worker. We have to think about what we are doing. It is helpful to bounce ideas back and forth with each other. Because you are working with smart people.

Why? It makes the company more money per coder…but what is in it for me: the coder.

  • Pairing is a way to learn a lot of things really really fast. Coders sharing information together can be a very powerful thing.
  • One person might know the syntax really really well, and another might know the codebase well, with their powers combined the can code better.
  • and… it is FUN!

“you forgot a semicolon” - THIS IS NOT PAIRING!!!!!11!!! (that is really really annoying)

The pairing station

  • Two monitors opposite each other, so you are sitting face to face.
  • But you are working on the same codebase. You are looking at the same screen, different monitors.

One useful pattern is having one person and one nagivator. The driver writes the code, and the navigator does the big picture thinking.

  • The driver fixes the syntax.
  • the navigator makes sure the code is doing the right think.
  • you TAKE TURNS bing the driver/navigator (too long as any one can make you crazy)

This is great with Test Driven Development (TDD)

  • One person writes the test.
  • the next person writes the code to make the test pass.
  • you then switch roles.
  • your tests should be very small in scope, so that you are not in any one role for too long (because that is annoying)

What is a good amount of time to pair with one person?

  • About a half-a-day is a good amount of time to switch pairs.
  • The weaker person should stay on the task, that way the weak dev. has to explain the code, which helps them learn.

When you pair with others, you get to LEARN from others.

  • For example, you might learn some cool vi tricks from someone else.

Sometimes you have to go solo. Wht do you do?

  • The rule: Anything that NEEDS TO BE MAINTAINED must be paired on.
  • If you don’t need to maintain the work (e.g. research), that work can (and should) be done solo.
  • Although these tasks are rare.
  • Because of this, the best teams are an even amount of people.

Why SHOULDN’T you pair?

  • There are many reasons why to NOT pair.
  • It is HARD WORK. You are basically working for 8 hours straight. (most of us don’t actually work for the entire day)
  • It takes a VERY disiplined team. Your team must come in at the same time, and they have to take lunch at the same time. Take breaks at the same time, and leave the same time. (that can be hard)
  • You have to be as alert as possible to pair well.
  • It is really hard when you have an odd number of people in your team.
  • It is tough when you only have a team of two people as well.

It is important to talk about things like text editors, when you are pairing. It is good to be open with your editor preferences.

Team size is important. It is really hard to pair when your team is very large.

  • Any team greater than 8 is hard.
  • The sweet spot for team size is 6-8.

Virtual teams can be tough. It is possible, but being in the same location makes pairing a lot easier.

There are no cubes in Aaron’s office. Cubes can get in the way. If you can get away with it, an open space is the best.

Hiring is hard. You have to hire people that are on board with learning new things and can get excited about working together.

If you and your pair cannot agree on a solution, a good thing to do is to shelf the problem and come back to it later. (but this can be hard to do on high priority tasks)

How do you get your team into pair programming?

  • Start small.
  • Pair on a project where it doesn’t matter if you mess it up.
  • Have people list the reasons why they DON’T want to pair.
  • Try to get buyin from the bottom up.

Try pairing with QA. It is good to learn how QA breaks your code.

Thanks to Aaron for the great talk! (PS: Aaron’s company, Algorithmics, is hiring…and they do pair programming)