Ask HN: Why is pair programming used or not used in top tech companies?
8 comments
I can't speak for everyone, but it's not used with any company I work with because otherwise I wouldn't work there. There's literally nothing I can imagine in software worse than being forced to constantly interact with someone else or code in front of them.
Probably because it doesn't work for everyone. Working closely with someone requires skilful communication and professional maturity, it's not as easy as the books made it out to be.
I was lucky enough to work in a serious PP company for two years, paired with ~10 people. I can appreciate PP when it's the right person, but when it's not, it can be downright unproductive.
A lot of software engineering practices like PP, TDD were preached like some kind of gospel but never stood the test of time.
I was lucky enough to work in a serious PP company for two years, paired with ~10 people. I can appreciate PP when it's the right person, but when it's not, it can be downright unproductive.
A lot of software engineering practices like PP, TDD were preached like some kind of gospel but never stood the test of time.
The problem with pair programming is when it is used dogmatically. "two people, one workstation, alternate who writes code and who writes tests, start with tests first and the other person makes the code work." This is draconian but can work sometimes. I've done that and it can be interesting but I'm largely not convinced that it is a solid use of time, especially on easier problems/domains.
However, pairing is great! Double so when one member is learning the ropes. Maybe one screen, maybe two. Give junior members the opportunity to drive so they get familiar in the code base. Maybe drawing boxes on a whiteboard. Asking questions. In short: _Collaborating_.
A good pair session doesn't have someone coding while someone just watches or instructs. It is truly collaborative. It could be a joint investigation or it can be a mentor/mentee situation. Generally, one person at a time on code branch, but not always. Maybe one person is knocking out something jointly understood while the other is following up on other things (documentation, asking other devs, prototypes, etc). It is a great way to share tooling, tips, tricks, code history, gain shared understanding, help destroy knowledge silos, and often two sets of eyes are better than one and can catch mistakes quickly when your own tunnel vision would have you wasting time debugging something in the wrong place.
I consider these types of practices to be similar to what you learned in school, like never start a sentence with "and", and other grammatical or format rules. As a novice, these rigid rules help. And then you grow up. You realize that you can bend and break all kinds of rules to achieve good results.
However, pairing is great! Double so when one member is learning the ropes. Maybe one screen, maybe two. Give junior members the opportunity to drive so they get familiar in the code base. Maybe drawing boxes on a whiteboard. Asking questions. In short: _Collaborating_.
A good pair session doesn't have someone coding while someone just watches or instructs. It is truly collaborative. It could be a joint investigation or it can be a mentor/mentee situation. Generally, one person at a time on code branch, but not always. Maybe one person is knocking out something jointly understood while the other is following up on other things (documentation, asking other devs, prototypes, etc). It is a great way to share tooling, tips, tricks, code history, gain shared understanding, help destroy knowledge silos, and often two sets of eyes are better than one and can catch mistakes quickly when your own tunnel vision would have you wasting time debugging something in the wrong place.
I consider these types of practices to be similar to what you learned in school, like never start a sentence with "and", and other grammatical or format rules. As a novice, these rigid rules help. And then you grow up. You realize that you can bend and break all kinds of rules to achieve good results.
It’s not that it isn’t used, more that it’s not encouraged long term due to several downsides.
First and foremost, top tech companies encourage autonomy. It’s hard to achieve or support autonomy for an engineer if they become too reliant on pair programming. It’s also difficult to scale teams and projects if you need a well matched pair to execute on them. Good pairs are hard to find and harder to sustain. And a fair number of programmers like their independence and aren’t excited to pair all the time. For these folks, pairing can be a big tax.
And I have come across engineers who become individually far less effective without pairing, so it can become a crutch. And over time, it becomes really hard to continue setting them up for success. Their pairing partner might leave or simply lose interest in constantly carrying them.
First and foremost, top tech companies encourage autonomy. It’s hard to achieve or support autonomy for an engineer if they become too reliant on pair programming. It’s also difficult to scale teams and projects if you need a well matched pair to execute on them. Good pairs are hard to find and harder to sustain. And a fair number of programmers like their independence and aren’t excited to pair all the time. For these folks, pairing can be a big tax.
And I have come across engineers who become individually far less effective without pairing, so it can become a crutch. And over time, it becomes really hard to continue setting them up for success. Their pairing partner might leave or simply lose interest in constantly carrying them.
It could be from a lot of the comments here around percentage of engineers not wanting any part of pairing. Cutting off parts of your job pool or even your current workforce is a tough request.
There's also incentives for individual success that soloing goes along with. Whereas pairing might lead to a greater product solution and with the lack of clarity around individual contributions. From what I've seen that's why pairing is implemented at smaller places or on separate products that are run as more of a smaller company.
Background: I was at a company that was forced into pairing and xp and said the same things about me not wanting to do it and leaving if I had to. I then tried pairing out and absolutely loved it. I moved to a larger company, for unrelated reasons, where we didn't pair and did not enjoy it. So I came back to a company that does pairing every day and I can't imagine working in an environment that doesn't pair consistently again.
There's also incentives for individual success that soloing goes along with. Whereas pairing might lead to a greater product solution and with the lack of clarity around individual contributions. From what I've seen that's why pairing is implemented at smaller places or on separate products that are run as more of a smaller company.
Background: I was at a company that was forced into pairing and xp and said the same things about me not wanting to do it and leaving if I had to. I then tried pairing out and absolutely loved it. I moved to a larger company, for unrelated reasons, where we didn't pair and did not enjoy it. So I came back to a company that does pairing every day and I can't imagine working in an environment that doesn't pair consistently again.
We do adhoc pair programming when mentoring a junior or going through a tough problem together.
It probably sums up to 2-4h per month. I wouldn't want to have it be obligatory or mandated. We use it as a tool when we feel it's useful.
It probably sums up to 2-4h per month. I wouldn't want to have it be obligatory or mandated. We use it as a tool when we feel it's useful.
I find it best to NOT pair program by default, ever. To date I haven't met a good developer that doesn't degrade in performance when being watched.
For Junior developers if helps, mainly because the most experienced developer can explain the coding mindset and codebase gotchas.
Having said that for rapid prototyping things that require a lot of knowledge in different domains, getting two SMEs in one room writing code without interruption can work well...for me. You can't force it, you can't mandate it, you can't expect it. Developers would do it themselves.
In my case, if I want to work on something complex and new, and I know part of the domain but not all of it, having someone that knows the other side can make things go much much faster. Replicating or adding little features I need to be left alone and just do the work.
For Junior developers if helps, mainly because the most experienced developer can explain the coding mindset and codebase gotchas.
Having said that for rapid prototyping things that require a lot of knowledge in different domains, getting two SMEs in one room writing code without interruption can work well...for me. You can't force it, you can't mandate it, you can't expect it. Developers would do it themselves.
In my case, if I want to work on something complex and new, and I know part of the domain but not all of it, having someone that knows the other side can make things go much much faster. Replicating or adding little features I need to be left alone and just do the work.
I might agree that in the beginning some developers aren't as efficient as being solo. But I've yet to find someone who doesn't benefit from being forced to explain their thought process in a clear and concise manner to a coworker. It benefits the pair and it benefits "normal" communication because of that constant practice.
I've found that even for devs who are completely against, which I was one, can come around on pairing given the space and time to succeed.
I've found that even for devs who are completely against, which I was one, can come around on pairing given the space and time to succeed.