Does Pair Programming Save Time?
In this video I want to talk about does pair programming save time and is it worth it at all to do pair programming.
Introduction
Hi I'm Oleksandr Kocherhin from monsterlessons-academy, where I'm teaching you how to become a developer or improve your skills of being a developer in learning by doing way. And if you are new here don't forget to subscribe and I will link everything that I'm mentioning in the description.
So let's get started.
Content
So the first question is what pair programming at all? It's when two people are working in pair at one machine. So only one of them is writing code, they discuss approaches, code and hopefully making things better and faster.
So I normally see two views of business on pair programming. Either companies like it or hate it. With hate I think it's obvious. They can't believe that 2 people will produce more output then just when two people are writing code separately. And they want to get the most out of the paid money.
The second approach is when companies think that pair programming is good any try to force people in doing it every week, make random pairs from developers constantly and they think that this is a silver bullet because they read somewhere that this is a cool thing and big companies are doing it.
As you understand both of this approaches are not healthy. So let's think about it benefits and when it works.
My first question here will be "What do we want to achive?". Normally we want pair to produce something faster or to share knowledge.
With sharing knowledge I think it's clear. If new developer is coming to the company with pair programming he can better understand how people are writing code in the company what standards and patterns they are using are why. So this is then dialog with check real code and speaking about pros and cons. And actually this is a really good approach. It says that company understands the need in onboarding process for new people and try to make it smoother.
When this process won't work? If the level in skills is different let's say junior came to the company and is in pair with senior it will bring really zero. Junior developer don't have a lot of experience and he can't grasp architecture and all concepts of the project just with quick glance. It can also be that the level of codebase is quite high, you are difficult architecture, abstraction and magic class that do hundreds things inside.
The problem that I see here is also that people normally see each other for first or second time in life. So they can have different experience, ways of doing things and it can lead to arguing more than to benefit
So the result here: Pair programming is good for onboarding of advanced developers when the code is not super over engineered and difficult.
The other variant is pair programming inside the team to do things faster. So the main question here if it's possible at all to make in pair features faster than alone. Yes it's possible but not with all types of features. If you have some basic stuff which everybody know how to do it makes zero sense to make pair because instead of 1 man day you will just spent on it 2 man days just because 2 people are sitting on the task.
The second case when it's not possible to do it faster together is when you need use/dig some new technology and it's more time reading documentation that coding.
Pair programming to do things faster only on complex architecture tasks where it's more about correct structure, difficult business logic, lots of usecases. In this case it's more like 1 person is typing and second person it controlling all possible mistakes. They you avoid to spent too much time on stupid mistakes or wrong ways of doing thing because they are approved by 2 people. Also very often you don't need to do pull request later because already somebody checked the logic of the code.
But of course there are problems here also. First of all pair programming works when people have same level of knowledge. It doesn't make sense to mix junior and senior because for senior either it will be boring or he will just code mostly alone. For junior it won't bring anything because he can't understand things that quickly and he doesn't have enough experience with all architectural patterns and stuff so he can't really discuss the best ways of doing something.
It also goes better when people already worked together some time, they write code in same way and that it's more efficient.
For me it's also a must that you should like to work with the person when you make pairing. He may not be your friend but at least you have okayish working relations and you don't hate him or his code. In other case it work be productive at all.
So the result here: We need people of the same level which like to work with each other and it should be a suitable task for this.
So stop doing pairing with different level of skills, when company forces you to do pairing, when you better code along, when features are too simple and most importantly when it doesn't bring you joy and excitement.
Call to action
I hope now you learned more about pairing and when it works.
Also don't forget to check my full courses regarding different web technologies. I will link them down in the description box below.
If you find this video helpful, don't forget to subscribe to this channel and hit subscribe button. And I see you in my next video.