Manage your growth by proactively Pair Programming

“Always two there are; no more, no less. A master and an apprentice.”―Yoda[src]

The first time I heard about Pair Programming was back in 2012. I was interviewing for a job at ThoughtWorks which is well known for aggressively practicing Agile. For this stage of the interview, I was given a programming assignment and was required to do half of it before the interview and the other half at the ThoughtWorks office. What I actually did not know was that I was being set up for my first Pair programming session with a ThoughtWorks developer!

You see, despite the fact that I had been developing for a few years in a local tech giant, I had never actually Pair Programmed before! We often worked on projects individually from start to finish. Whenever we found a blocker, there was always a senior developer (Martin) in the office with a lot more knowledge and was always happy to be consulted. However our version of “pairing” was you walking over to Martin’s desk, him grabbing your laptop and fixing the issue while you watched. Everyone that visited Martin’s desk walked away lamenting how the guy is “baaaad” or better said, badass! It was not long before I myself was in Martin’s shoes and to be honest, solving people’s problems can make you feel indispensable.

Anyway, I walked into the lavish ThoughtWorks office ready to defend my solution or build on it some more when asked. I was ushered in by Maria(then recruitment manager) and led into a boardroom where two developers welcomed me and offered me a seat in front of a laptop. I couldn’t help but notice the glass boundaries of the room that were filled with snippets of code and the Xbox mounted on the only side that had a wall. I smirked at the thought that I could convince my current workplace to get a gaming console.

“So are you ready to begin?” one of the developers(who is actually now an Andelan) asked.

I nodded and was shown the second half of the assignment. I dug right into it, carefully reading the instructions and thinking of possible approaches to solving the problem.

“Tell us what you are thinking”, one of the developers nudged me. I turned, looked at him and said, “give me a minute”. I soon had an idea of the approach I wanted to take and immediately opened the IDE to start coding it.

“Why are you using this algorithm?” The developer nudged again. At this point I was in the zone and probably did not even hear what he said. I think he gave up and let me finish coding my solution. Anything he said thereafter could have been integrated with the thoughts in my head.

“It’s done” I said about 10 minutes later with great satisfaction. The developers who had reclined in their chairs sat up and looked through my solution. They started to break it down and take me through an alternative approach which would have reduced the complexity of my code.

To cut the long story short, I did not get the job but one thing I walked away with was the resolve to work in an Agile environment that not only practices Pair Programming but also follows the methodology right up to task/product delivery.

I left my job at the local tech giant and moved to an agro business startup that was pretty strong on Agile. We used the Scrum methodology religiously and had a good number of consultants fly in to give regular trainings and observe our process. It was serious stuff. One thing I also later did was Pair Programming. It was not easy for me at the start though, there were a couple of things I had to unlearn before I could truly reap the genius of Pair Programming.

I remember one of my first Pair Programming sessions was with a colleague called Able(not real name) who was equally as strong and experienced. We were also both very opinionated and working with him could be compared to having Ronaldo and Messi playing on the same team. Let’s just say, it did not go well. We did not agree on anything, from the Node.js folder structure to what templating engine (jade vs ejs) to use. Luckily, our team workflow required that rotate every week so I did not have to work with him again until after a long time. By the time we got to work together again, I had worked with a lot of other developers. I had learnt from the more senior developers to be better at listening and have an open mind. From the junior developers, I learnt to be more articulate in my thought process so my teammate could follow along as the driver. The pairing sessions that followed between myself and Able were so productive that our team got the excellence badge one quarter. We delivered a lot faster and the quality of our work was top notch.

Fast forward to 2018, at Andela I have had the privilege of working with some of the best minds on the continent in both Bootcamps and Simulations. Right now as a Simulations Learning Facilitator, one of the most favourite part of my job is solving problems with team dynamics and figuring out how to improve on team performance.

A couple of weeks ago, I had to deal with a team that had an interesting mix of strong developers that had experience in the stack they were working on and others that were still trying to catch up with the new environment. At one of the end of sprint demos, the more experienced developers confidently demoed their features which were fully implemented and tested. The other developers however had lagged behind on their task and were being thrown under the bus by their experienced counter parts for letting down the team.

It is interesting how poor team dynamics manifested itself despite the fact that this team always sat within close proximity: so near and yet so far, some would say. It was obvious that their team cohesion was being put to question and some people were struggling to cope with the rapid delivery.

One obvious solution to this problem was..yes you guessed it, Pair Programming. During my weekly syncs with the Technical Team Leads(TTLs) and Product Owners(POs), we discussed this issue at length and came up with a strategy to solve this problem. We agreed that we should do Pair Programming as required by the Simulations Program anyway but with a caveat. The experienced fellows would be paired with the struggling ones and they were strictly navigators while those that struggled took on the role of driver. The results were quite impressive. The team was not only able to complete all the tasks on their PT board, but went ahead to add more tasks to the board which they also completed. What was more impressive however was the fact that their end of week demo showed a more united team and everybody felt better about their learnings for the week.

At Andela, we work in a unique space where you have over 100–500 brilliant developers at different levels of experience seated under the same roof every single day. There is immense opportunity to share and tap knowledge from someone who has faced the same blocker in the past. One of the reasons why the Aviation industry is still the safest and most efficient means of transport is because unlike the Automotive industry that is discrete on their failures, Aviation faults are publicised and there is a collaborative effort in ensuring that these faults never happen again. Pair programming is a great opportunity to leverage on someone’s knowledge to fix a fault in your technical implementation.

So, are you struggling with a task today? Ask to pair with someone on it and see that indeed two heads are indeed better than one.

Do you need to hire top developers? Talk to Andela to help you scale.
Are you looking to accelerate your career as a developer? Andela is currently hiring senior developers. Apply now.