This is a story of pair programming in typless team.
It was almost a year ago when I was reading a book titled Peopleware. I decided to read it because I was struggling to lead our time effectively. Firstly, we’ve spent too many hours on programming and not enough on planning. Furthermore, everyone got easily frustrated and demotivated. As a result, we were blaming each other for bugs and errors.
Pair programming – could this help us?
After reading the abovementioned book, I started searching for practices that we could introduce to our workflow to improve team spirit. When I’ve come across pair programming, it immediately drew my attention. Although I didn’t know how I’ve decided to start with it. I called a meeting and introduce it to my teammates. They were all in. So we decided to start with it next week.
It’s not that easy
Next week has come. I scheduled time slots for our pair programmings sessions. At first, we thought it was a bit awkward. Sitting there, next to your colleague, just watching the screen and maybe talking. We were trying it for 2 or 3 weeks but it seemed like it wasn’t helping. Another deadline came and it somehow passed away from our schedules. We were in a hurry all the time. Consequently, old habits resurrected and we were back on point zero.
It comes natural
Some team leads would probably give up but I didn’t. I was reading much about it and it seemed that we were doing something wrong the first time. Although I was doing a lot of research I forgot about it.
At the end of 2019, we started our new project. As we began, I called a meeting to write down basic specs for it. After that, we’ve begun designing our database. I was planning to do it in a single day. Although we thought it an easy job, we spent three days finishing it. We talked, argued, write on the paper, draw on the blackboard, cleared the blackboard back and forth. As a result, we have a database design that was simple and efficient. Nice job!
How did we really start?
Designing the database wasn’t an actual pair programming, but it was a leap towards it. After we’ve finished it, we had to develop our pipeline for building feature vectors. All of us, frontend guys also, sat in front of the blackboard discussing how we should do it. We’ve rethought our previous approaches, validated new ideas, and discussed possible improvements. I didn’t have to schedule any pairing session. It comes from our common desire to succeed. Seems like nothing particular has changed, but there was something. I, as team lead, for the first time didn’t strive towards fast delivery but towards the quality of the product. Finally, we’ve also started to do pair programming as expected. One guy behind the keyboard and another next to him.
Pair programming – what we’ve learned?
We’ve continued to do it while developing our product. As days passed we’ve started to notice some changes:
- our approaches for building feature vectors became simpler,
- our code base for ML reduced for about 70% and is still reducing,
- we’ve started to do better abstractions, encapsulations, and tests,
- fewer bugs were discovered per week,
- team spirit is better,
- iterations are faster.
I wouldn’t say that pairing is the silver bullet to solve all development problems. On the other hand, it can improve a lot of your things. Think about it, it is actually code review on the fly. It also helps to solve disagreements between teammates more often. Therefore, I would definitely encourage you to introduce it to your team. Nevertheless, as small things as a change of thinking of one team member can lead to great changes.