I’ve always liked pair programming, since my college times. I remember doing coding exercises spending late nights at the computer lab and we were always working with your partners. And you would talk to everyone in the room trying to figure out how to solve things, you’d sit with people from other teams and share code. I didn’t know you’d call this pairing then.
And then I started doing an internship to get my degree, and I was assigned a project with someone from my same university. And we would work together a lot, we’d sit together solve problems we had with Enterprise Java Beans (OMG!!) the Oracle web server and related technologies of the time for hours. And we’d code together on the same things, sometimes at my computer or his and I still didn’t know it was called pair programming.
And as I started working after I moved to Spain I was working as a consultant and I didn’t do much of that. Yes I’d talk to colleagues and solve some things together but it was not well seen to work together. How can you have two people working on the same thing? It would take double to get things done they’d say.
And then I had my first Rails job, a totally different environment, and we worked together a lot, sit with someone for many hours solving some problems, debugging, creating things and having fun. It was at this moment when I started to learn about pair programming.
It was a thing, doing that which always seemed to me like the best way to work actually had a name. And there was a lot of people that talked about this subject, a consultancy like Hash rocket would do it and talk about it, what worked well for them and it was good to realise there was a movement of people promoting this work.
And so since then I’ve had a few jobs and I’ve always been bit of a proponent of it and I’ve always tried pairing whenever possible since I enjoy working with others this way.
The software we’re building is getting more and more complex with time, the demands of our users become ever increasing and we’re required to handle many different parts. With micro services and the cloud this is only getting harder. And for me it’s becoming more clear that in order to solve this things what we need is more collaboration and that pairing is a more effective way of getting work done.
There is only so much information one can keep in their heads when you are pairing you have much more capacity. When you have a good partner and you’re driving you can feel more relaxed since someone else is spotting many little mistakes that help things flow better instead of hitting them and having to fix them.
When tackling a problem and there’s a need to discuss things and you’re pairing you have immediate access to a smart person sitting next to you to help you discuss alternatives and make a decision.
Writing tests for a feature and having a partner is very useful going through edge cases, suggesting possibilities that you haven’t considered making sure things are more robust from the beginning.
All the features done with a partner get an automatic +1. Features developed pairing are better designed and more robust and other team members will feel usually more inclined to accept them.
Pairing is a social skill that needs to be developed, it’s not the most natural way to work for people, you need to learn how to work with your partner when you’re writing the code and when you’re the “co-pilot”. It takes time to break old habits too, getting rid of the constant distractions and focusing on the task with your partner can be challenging.