- Figure: Do you always try to work in pairs?
- Less time stuck on a problem - you have someone familiar with the project to help you work through the problem
- Your code will have less strange workarounds - because if something doesn't add up to a developer, he has someone to ask
- Cleaner code - because you know someone else is going to be looking at your code
- Support - when you need changes down the track, you have two people to call on
But I don't promote classical pair programming which is two developers on one machine. At SSW we use our own type. We do put our developers in pairs, but they each have their own computer.
It's also a good idea for non-programmers to work in pairs. You can keep each other motivated, there is always someone to help if you get stuck, and you absorb knowledge from each other. Experience shows that developers are more productive this way.
If you are not sitting next to a person working on the same project, then fix it. If you cannot then at least mention it to your manager.
- Figure: Bad example - This is normal ‘pair programming’, two people working at one PC
- Figure: Good example - This is ‘pair working’, two guys working on the same project, with their own laptops, but sitting very close to each other
Is there an overhead?
Some projects are done quicker with two people - especially when they are complex. But on most projects there is an overhead, because of the extra communication between the developers - you now have to please someone else - not just yourself.
We generally estimate the overhead as 20% extra. But this is more than offset by the cleaner code and better solutions that come from two brains working together.
What if you are working remotely from each other?
If you are really working closely together, you will be using an application like
TeamViewer to view one another's desktops so you can help each other out when necessary. You should have
TeamViewer showing on a 2nd monitor.