Mark Needham

Recently my pair and I were trying to merge some changes into our code that we had just picked up fron updating from the trunk and realised that we weren't actually sure how to resolve that merge since it seemed to conflict with what we'd been working on.

We hadn't checked in for longer than we would have liked to due to a bit of a checkin pile up which had happened because the build on the CI server had been failing for a few hours due to a temporary problem we were having with an external dependency.

Another pair were working on some code which was around the same area of the code base as us but for a different feature so we hadn't been working together too closely.

Usually when faced with this type of problem my default approach would be to go to the Subversion logs and go through each of the changes in their checkin until I could work out what their change was all about and how it fitted in with what we were doing.

On this occasion we didn't do that but instead called over one of the guys in the pair to ask if they could explain what changes that made in their latest checkin and how we would need to change the code on our machine to work with those changes.

My colleague took us to a whiteboard and sketched out what they were working on and the approach they were taking to achieve that.

It took less than a minute to do this and after that it was really obvious what changes we need to make and in another couple of minutes we'd made those changes and had our code functioning again.

It's certainly a useful skill to be able to merge code by scanning through the change logs but it's also useful to remember that software development is generally a team game and that we can get things done so much quicker if we work closely with our team mates.