This blog is my experience with pair programming while we were working on interviewbot. It is a collection of events from Aug2016 – Jan2017
Pair Programming uh?
Trust me this concept is not that alien to you. Remember your school days where you share the same system with one other classmate and work on exercises together? That is what pair programming is. Except the fact that you build real-time applications with your colleague at your workplace.
My first encounter
It was after a month in my first job as a product developer. I was in my training, one of my super intelligent colleague Ahmad Faizal, made me sit next to him and watch him build a prototype version of interviewbot(Ibo). The process of sitting and watching made me learn a lot of things. It wore out the Java programmer in me(which I was in college) and introduced me the pythonic way of coding. I learned Django from him. He was a man of best practices and optimization. I got amazed by Faizal’s way of thinking I tried to imitate that, and it worked sometimes. This process brought out a better version of a programmer in me. I realized this 3-4 months later where I pair programmed with another colleague where we took our product from alpha to beta.
One new thing
Our team was always famous for getting exposed to new technologies and practices. Dorai makes sure that we learn and work with new stuff or at least get a taste of it. He very well knew we wouldn’t stop there.
In test-driven development, we write the test cases before even writing the functionality thereby leading you in the process of bug-free software.
Pair programming is an aspect of TDD where you program in pairs where one person would write a test-case, and the other person would write the actual code to pass that test-case. Hence we will have two minds working together, thinking about all possible cases for a given functionality thereby creating a robust software.
You have to fail first
During the session, we were asked to do pair programming, so I joined with my colleague Vinay, It was a fun activity. First I would write a test-case. Obviously, it will fail because there is no code to support it then Vinay would take his turn and write the functionality to pass my test-case.
If this was all greek and latin to you, don’t worry I will help you with an example. Let’s say you want to do TDD for login functionality here are few things you consider
- It should be a valid email ID.
- Password length should have min length of 6.
- Should have a least 1 capital letter and so on.
All these conditions will become test-cases for the login function you hadn’t written yet. Once you run the test case, it will fail at all these conditions. Now it is for your pair programmer to write the functionality to pass those test cases. For every iteration, you will swap places between writing code and test cases.
As a part of the TDD session, we were given assignments. This time we got stuck in a lot of places. We helped each other referring to our notes. I loved the process. It was like working with 2 brains.
In the field
After the session, We didn’t incorporate TDD into our process. Until one day when Vinay was scratching his head with a bug for 2 hours until I went by and we both talked out loud and fixed it. Vinay gave me a big HiFi “Pair programming is great.” From that day we never wasted 2 hours on a bug fixing.
Pair programmer could be your ambulance service whenever your code is broken.
It was a week before the 2nd TDD session when we were happy with how Ibo was shaping up and wanted to include more features in it. That’s when we realized the code needs serious modularization. Vinay and I went on severe brainstorming and rearchitecting the whole project into multiple rest based modules that work independently and started working on it. We created separate git branches so that we can build basement parallelly. Again I had no idea how Django rest framework(DRF) works. I sat with Vinay and saw him building one module using DRF. This was when I realized what I had with Faizal was also pair programming but in a different mode.
In pair programming nobody teaches you anything, the beauty is how your brain absorbs all those little details and retrains the mental model of how you program.
The same happened to me with Faizal. I absorbed all those details. I killed him with lots of questions, called him for help more than a few times until I got hold of it.
By the end of 2nd TDD session, we were developing the core module of interviewbot. This time We decided to go with TDD consciously. We thought through lots of cases and at the end of it, we had a modularized interviewbot.
It was around the same time when we incorporated 1-week sprints into the product building process. You decide on features that need to go into the product, built it, test it and release it.
During sprint-3 we just found that there were too many features needed to be done all in the core module of ibo. There is no way that we could split it across git branches. Though the 5-day sprint extended to 7 days It was the most successful sprint in the history of ibo. It turned out to be the best sprint ever with maximum and most essential features implemented and comparatively less number of bugs. The sprint ended with a big HiFi on a Friday evening.
It went on like that for 9 sprints when we had a major version release.
FAQ – Freaked and Asked Question
Won’t pair programming take more than solo programming? How productive will that be?
A good piece of software is not just about quantity but also quality. The amount of time required to fix bugs will drastically reduce. One other cool thing about pair programming is that the chance of making syntax errors will reduce drastically. Don’t trust me? Try missing a semi-colon when someone is watching you code over your shoulders.
I already mentioned that it’s like one person with 2 brains with complete control over the same product. These brains working separately would have already spent a lot of time on integration issues.
What I got out of pair programming?
I was a queen of Panicking. I will freeze every time something goes wrong but Vinay is a boss of being cool, he was under control no matter whatever goes wrong. As I already mentioned you just absorb stuff when you do pair programming. I learned this quality from him and is helping me in big time.
Django and DRF
I learned both Django and DRF out of pair programming with someone who was already proficient in it. I got kick-started quickly.
A Good friend
By the time interviewbot evolved into a stable product Vinay had become a good friend of mine. if not he would have been a silent alien working at some corner.
Quality of code
You learn new ways of coding,
When you start off pair programming, you often have to explain bits of your code to your partner explaining why you choose that particular approach. After a while, you tend to write the code in a way such that it is self-explanatory. In other words, I now write my code in a way which makes it more readable.
- If you pair program with a person with whom you don’t have a good rapport you are going to have a terrible experience.
- It is not suitable for UI development.
- Pair programming is not suitable for long-term.
- The learning worked for me because I won’t move my eyes from the monitor when someone is working. It was not the same when I tried it with my juniors.
My phase of pair programming came to an end when Vinay had to move on with his career.
Will I Do pair programming Again?
A big yes. There is a lot of this you can learn when you work with someone. Pair programming will enable us to peek inside the pair’s brain and grasp how much ever knowledge we want.
I would suggest all the starters out there to try out pair programming with someone who is senior to you and the seniors to open up and help the newbies.