Day 2. Main Course.Pair programming is AWESOME!

Tom Harker
makeorbreak
Published in
2 min readMay 25, 2016

So today I had my first proper day of pair programming with a randomly assigned partner. I absolutely loved it and would never want to learn coding any other way after today. Two brains working together with a driver and a navigator is so much better than one brain trying to do both jobs at the same time. Now don’t get me wrong — we struggled like hell! But we struggled together and we coped together and we solved together.

We began a challenge which involved working on a program which would run a Boris Bikes docking station. To do this while pair programming we had to set up Github so that we could access each other’s work and edit it. This was hell at first. Github, despite being invented to make things easier, can be incredibly hard to get the hang of at first. After about two hours of struggling we finally solved our issue and actually started writing code. But here’s this important thing: I understood exactly why the problems occurred, and I understood it because I had discussed it with my partner and we had both tried to solve it in different ways.

Once the coding began, we finally got into the swing of switching places every half hour. Okay…maybe not every exact half hour but we got the hang of switching roles every now and then with a break in between. It was during this time that I began to truly appreciate the value of a 5 minute break. A short break refreshes your mind and gives you time to reflect on what you have just been doing. Without them I probably would have gone mad with frustration.

So anyway, we began using test-driven development which was a completely new experience for me. It discourages jumping straight into a challenge and writing 10 lines of code without a second thought. Instead you are expected to test your code literally every time you make a small change to see if it fails or returns an error, even if you already expect it to. If it does, you need to understand what the error is and why it is occurring. In other words: ERRORS ARE GOOD! I found this hard to get the hang of. It is very hard to resist the urge to keep writing code without testing, but I understand its value. It means that the code you have written is less likely to contain bugs and will be nicely refactored. You will therefore save time in the long run.

When I looked back at today I could not believe how much I had learnt in one day despite not completing many of the challenges. It makes me wonder how much I will have learnt by the end of the week.

--

--