Mark Oliver's World

Posted: 01/07/2021

Remote Pair Programming

In order to get upto speed at my new job, I have suggested I Pair program with some of the developers.
This will help me get upto speed, help me learn the systems, the processes, the people and the tools.

It seemed like the existing engineers were hesitant, but that was quickly overcome. I believe the hesitancy was down to not really liking the "video on" meetings. Although most are now on board with that - I'll write up my thoughts on this in another post.

So with them onboard, I have spent this last week pair programming.

Myself and one of the other newbies were given a task to create the capability to store large files in Azure Blob Storage.
Neither of us had used this functionality of Azure before, so we decided to pair up to tackle it.

We both read a little around the subject, sharing links over Chat about the API and the capability, and then we got together using MS Teams video calls.

We wanted to write code together in a Pair Programming way, while also taking a Test Driven Development (TDD) approach to the task.

We started a Teams video call, both booted Visual Studio, and then tried the "Live Share" option.
This at first did not work, we were dealing with 1 solution with over 300 projects in it, and VS was struggling.
Some of it was attributable to later discovered hardware issues.

Once we also figured out that being signed into VS gave you more capabilities with editing the code together, the point of LiveShare became apparent.
Unfortunately, Visual Studios Intellisense was not working over LiveShare, which is apparently a bug that is being worked on. The LiveShare "guest" was at a huge disadvantage due to this, so we found doing a Screen Share as well as the LiveShare helped. The feedback for the "guest2 was much better.

We managed to write tests together, then build the code to meet those requirements.
We problem solved together, we learnt about each other, our coding habits, the way we like to approach issues, design solutions and code.
We helped each other to improve our way of writing tests, how to use VS, how to build code to be tested, and improved our use of TDD.

We found a regular code commit and swap of the main VS user/guest helped, as the lack of Intellisense was frustrating.

We also found that VS Extensions live Fine Code Coverage and SonarLint were helpful.

We also kept our Jira task upto date with the "TODOs" for the development work. 2 people generated a lot of thoughts, and working through them all at the same time meant we kept getting side tracked. Writing them back to come back to kept us on track, and allowed us to focus.

Once the bulk of the coding was over, we again separated to separate VS instances, and tidied up different parts of the system, adding identified missing tests and documentation with the legacy code.

Then we came back together for testing.
The system we had built was a plugin to a much larger system, and up to now had only been executed through unit and integration tests. We needed to test it in the system,
However neither of us had ever run the system or used it before.

Pair programming again helped here. We both had learnt different things about the system in the previous week working apart, therefore when we started to run the system for testing, between the 2 of us, we figured our way through it.

We still have testing to go, due to some blocking system config issues, but I have found the Pair programming of the last week to be very beneficial for me, and I hope the other engineer too.

Thanks for reading this post.

If you want to reach out, catch me on Twitter!

I am always open to mentoring people, so get in touch.