Pair programming, team ownership and collaboration -- Oh crap!

For me, like many others in our field, talking to people and collaborating wasn't as natural as coding and designing.

I never needed to talk out a design, it would just happen. I loved creating software and I was quite good at it. In a few short years I went from code monkey to architect and project engineer.

In all this time, I never developed a sense of team, community or sharing. I had a hard time communicating my designs; I never thought about them, I just did them. I had difficulty listening.

When I first got to Oxygen, with only pair programming, I was completely frustrated. I was use to excelling and being the hero of the team.

At pairing and communicating I, well, let's just say it didn't come so naturally.

For me, the most difficult part of pairing and code ownership is giving up what's best for you and substituting it with what is best for the team. This is a concept that is very important for the entire team's productivity and happiness.

In our world we have a lot of brilliant developers, with a lot of brilliant ideas. Our designs are more of an art than a science and with any art, it is a personal expression. This is why collaboration, sharing and pairing is so difficult -- in our minds our design is always really good.

And for each individual that is true.

But for someone else, a solution that brings you great success may bring them great frustration and pain.

What is the solution? How can we all agree? In what ways can we share our knowledge?

I'm not sure... but I think about it a lot.

While differing opinions can bring the best ideas, spending an entire pairing session (or worse days, weeks, forever) bickering about differing opinions is much worse than not bringing your ideas to the next level.

In pairing, when you have two opinions, the best option is to choose an opinion and run with it. If its not the right solution, it will be obvious right away.

However, sometimes its not a wrong decision, its just not the better solution and the pain of the decision may not be felt at that moment.

Will the frustration of the person be felt in the group? Probably not if they are sometimes heard. If your environment has a few people who are more stubborn than others, you may have some frustrated developers who need to get their way more often.

On any team, with each pair, you will eventually find a groove. How long it takes and the style of your solutions with depend on the individuals of the team. And the style you find may be completely different than what you do on your own.

Whatever gives your team the ability to keep their velocity, happiness and quality high is the best practice.