Some months ago we were asked if we want to participate a pair programming experiment. The guy who asked was "Code-Cop". Of course, this is not his real name but it's easier for you to understand what he does. He is fanatic about code quality. He likes his code being in order, e.g. nicely formatted, readable, proper named, designed, tested etc. And trust me, these are not just words for him. Read the full story about Code-Cop and his craftsmanship tour on his blog.

My first thoughts

I did pair/xtreme programming in 2001 and thought it would be nice to do it again. But I thought it could be a risk because I found my own source style and defined my own quality standards over the years. I thought that my quality standard is very high and I'm a professional developer with a lot of experience. You could say that I have a lot of self-confidence... hm... not really bad. What I also learned over the years was that you can't be successful without changes. Every change is a risk because you learn/see something new and maybe you don't like it. But you don't know what you like until you've tried it. This is the most important experience - from my point of view.

So it was great to have this new opportunity and it's always cool to work with same minded people

The experiment

We planned to work 3 days with Code-Cop. It was not clear if one person or two persons should work with Code-Cop. We wanted to use the experiment as mechanism of getting input from "outside". The more different perspectives, the better. We had many different tasks for the 3 days, but not all were good because I'm researcher and love playing around with new technologies/frameworks and products. If you do pair programming, you should develop.

I had one task that was open for a while and it frustrated me that it was open. It was the optimization of our JVx build process and fixing some failed test cases. Don't misunderstand me... I hate red test cases and my tests are always green, but it's boring if your tests are green on your developer engine but fail on the build server (different encoding, different OS, ...). Another bad thing was that the build ran about 80 minutes!
The problem were our unit tests because we mixed manual (performance, timeouts, ...) and automatic tests. My plan was a build time around 10 minutes.

The optimization and tuning was the task for one day. Another task was the implementation of a new feature for our product VisionX (a very short task for about a half day). The rest of the time was hardcore coding with Martin, because we have one really complex model class in JVx. Its the MemDataBook class and it grew over the years. It's about 5000 lines with about 3000 LoC. It's a big class but it's not a monster. It's the biggest class in JVx and has the most logic. It was the right class for pair programming

How we worked together

We worked together on the same machine with a big external screen, two keyboards and two mice. The first day was a challenge because Code-Cop and I tried to find out who's the top dog Not that bad, but it was a big difference to work with another person on the same machine and the same problem (and it didn't help that we are ambitious and dominant). We had different ideas and sometimes different solutions for a problem. I tried to dominate the keyboard because I was used to. One tip: Don't do this, because you don't focus on the problem.

We had great discussions and smaller brainstormings about code quality. It was awesome.

From the second day, everything was in flow because the first day was to get to know the other person. We did our tasks and I had some extra tasks/ideas that could be useful.

The rest of the second day and the third day were reserved for Martin. It was funny to see them in action, because Martin got a "Mouser" and "Keyboarder". It was a long awaited dream of him - a person who understands what he think and can produce source code of his ideas. Of course, they had a tricky task and it wasn't possible to finish the task in two days, but Martin got some new ideas. And last but not least - they had fun!

All 3 days were awesome because Code-Cop was productive from the first minute. We didn't waste time to explain how our framework works. This only is possible if you work with geeks.

Lessons learned

• It's great to try new things
• Work with geeks who are professional and have a lot of experience (if you find someone)
• Use the keyboard and learn most important shortcuts of your IDE. You save time!
• Don't think you are professional enough. There's always space, but be solution and practice-oriented.

The experiement was awesome and Code-Cop is a pro' geek. We had a great time and I can recommend such experiments.