3 ms·

Pair programming 100% of also works. It's unfortunately widely unpopular, but it works.

jakevoytko 7mo ago
I also think we're going to see a resurgence of either pair programming, or the buddy system where both engineers take responsibility for the prompting and review and each commit has 2 authors. I actually wrote a post on this subject on my blog yesterday, so I'm happy to see other people saying it too. I've worked on 2-engineer projects recently and it's been way smoother than larger projects. It's just so obvious that asynchronous review cycles are way too slow nowadays, and we're DDoSing our project leaders who have to take responsibility for engineering outcomes.
- yonaguska 7mo ago
  For anything complicated or wide in scope, we've found it much more productive to just hop on a call and pair.
- player1234 7mo ago
  [dead]
hallway_monitor 7mo ago
You are exactly correct. As to why it’s unpopular, I believe it’s just that no one has given it a fair try. Once you have done it for at least 20 hours a week for a few weeks you will understand that typing is not and has never been the bottleneck in programming. If you have not tried it then you cannot have an opinion.
- palmotea 7mo ago
  > You are exactly correct. As to why it’s unpopular, I believe it’s just that no one has given it a fair try. Once you have done it for at least 20 hours a week for a few weeks you will understand that typing is not and has never been the bottleneck in programming. If you have not tried it then you cannot have an opinion. I haven't tried pair programming except in very ad-hoc situations, but doing it all the time sounds utterly exhausting. You're taking programming, then layering on top of it a level of constant social interaction over it, and removing the autonomy to just zone out a bit when you need to (to manage stress). Basically, it sounds like turning programming into an all-day meeting. So I think it's probably unpopular because most software engineers don't have the personalty to enjoy or even tolerate that environment.
  - sodapopcan 7mo ago
    Well as the person you are replying to said, it's hard to have an opinion when you haven't actually tried it. I don't find it like that at all. Also, it doesn't mean you get NO solo time. Pairs can decide to break up for a bit and of course sometimes people aren't in leaving your team with an odd number of people, so some _has_ to solo (though sometimes we'd triple!) But it's something you have to work at which is definitely part of the barrier. Otherwise, saying it sucks without giving it a real try is akin to saying, "I went for a run and didn't lose any weight so I feel that running is exhausting with no benefit."
    - palmotea 7mo ago
      > Well as the person you are replying to said, it's hard to have an opinion when you haven't actually tried it. I don't find it like that at all. I don't need to try pair programming because I know how that level of constant social interaction makes me feel. > Otherwise, saying it sucks without giving it a real try is akin to saying, "I went for a run and didn't lose any weight so I feel that running is exhausting with no benefit." No, what you're doing is sort of like if you're raving about the beach, and I say I don't like bright sun, and you insist I need to try the beach to have an opinion on if I like it or not.
      - sodapopcan 7mo ago
        I wouldn't call "work" social interaction but I get ya. It's my biggest pet peeve of this industry: it has a whole lot of people who just don't want to talk to anyone. It is what it is, though.
        palmotea 7mo ago
        > I wouldn't call "work" social interaction but I get ya. IMHO, social interaction is anything where you interact with other people. > It's my biggest pet peeve of this industry: it has a whole lot of people who just don't want to talk to anyone. That's very black and white thinking. I like talking to other people, but too much of it is draining. Every day spending all-day or even a half-day working directly with someone else? No thanks.
- sodapopcan 7mo ago
  I agree. The main reason people give for not liking it is that they say _they_ find it exhausting. _Everyone_ finds it exhausting, at least at first. That mostly stops being the case after a while, though. It can still be tiring but it found it to be a good kind of tiring because we were getting so much done. The team I used to pair on worked incredibly quickly that we started doing 7 hour days and no one noticed (although eventually we came clean). I find it depressing and dystopian that people are now excited about having a robot pair.
iampims 7mo ago
I’ve started pair programming with Claude and it’s been pretty fun. We make a plan together, I type the code and Claude reviews it. Then we switch.
- lelandfe 7mo ago
  You’ve made the analogy but I don’t think you’re actually doing an analogous thing. I think you’re just talking about code review.
alkonaut 7mo ago
The problem is that you can only meaningfully pair program with programmers. The people involved in architexture/design meetings might not be programmers. The questions that arise when 2 programmers work might not be resolvable without involving the others.
- pydry 7mo ago
  Nonsense. I pair all the time with stakeholders. If you strip out all of the cucumber nonsense this is essentially what BDD is - fleshing out and refining specs by guiding people through concrete, written example scenarios. I also often pair with infrastructure people on solving a problem - e.g. "im trying to do x as per the docs, but if you look at my screen i get an 1003 error code any idea what went wrong?". Or, people on a different team whose microservice talks to mine when debugging an issue or fleshing out an API spec. It's true that this isnt possible in plenty of organizations due to the culture, but lots of organizations are broken in all sorts of ways that set piles of cash on fire. This one isnt unique.
  - deleted 7mo ago
    [deleted]
  - nomel 7mo ago
    you're missing the context of this thread. for the purpose of code quality/review, it can only work if the other person is a programmer.
    - pydry 7mo ago
      I interpreted what they meant as "pairing doesnt work with non coders doing non coding design/architecture/requirements". Not "pair programming doesnt work with non programmers doing pure programming" coz it doesnt make much sense why you'd even attempt to do that. They dont care and they will get in the way.
lostdog 7mo ago
Maybe it's time to do pair agentic engineering? Have two engineers at the screen, writing the prompts together, and deciding how to verify the results.

I also think we're going to see a resurgence of either pair programming, or the buddy system where both engineers take responsibility for the prompting and review and each commit has 2 authors. I actually wrote a post on this subject on my blog yesterday, so I'm happy to see other people saying it too. I've worked on 2-engineer projects recently and it's been way smoother than larger projects. It's just so obvious that asynchronous review cycles are way too slow nowadays, and we're DDoSing our project leaders who have to take responsibility for engineering outcomes.

yonaguska 7mo ago
For anything complicated or wide in scope, we've found it much more productive to just hop on a call and pair.
player1234 7mo ago
[dead]

hallway_monitor 7mo ago

You are exactly correct. As to why it’s unpopular, I believe it’s just that no one has given it a fair try. Once you have done it for at least 20 hours a week for a few weeks you will understand that typing is not and has never been the bottleneck in programming. If you have not tried it then you cannot have an opinion.

palmotea 7mo ago
> You are exactly correct. As to why it’s unpopular, I believe it’s just that no one has given it a fair try. Once you have done it for at least 20 hours a week for a few weeks you will understand that typing is not and has never been the bottleneck in programming. If you have not tried it then you cannot have an opinion. I haven't tried pair programming except in very ad-hoc situations, but doing it all the time sounds utterly exhausting. You're taking programming, then layering on top of it a level of constant social interaction over it, and removing the autonomy to just zone out a bit when you need to (to manage stress). Basically, it sounds like turning programming into an all-day meeting. So I think it's probably unpopular because most software engineers don't have the personalty to enjoy or even tolerate that environment.
- sodapopcan 7mo ago
  Well as the person you are replying to said, it's hard to have an opinion when you haven't actually tried it. I don't find it like that at all. Also, it doesn't mean you get NO solo time. Pairs can decide to break up for a bit and of course sometimes people aren't in leaving your team with an odd number of people, so some _has_ to solo (though sometimes we'd triple!) But it's something you have to work at which is definitely part of the barrier. Otherwise, saying it sucks without giving it a real try is akin to saying, "I went for a run and didn't lose any weight so I feel that running is exhausting with no benefit."
  - palmotea 7mo ago
    > Well as the person you are replying to said, it's hard to have an opinion when you haven't actually tried it. I don't find it like that at all. I don't need to try pair programming because I know how that level of constant social interaction makes me feel. > Otherwise, saying it sucks without giving it a real try is akin to saying, "I went for a run and didn't lose any weight so I feel that running is exhausting with no benefit." No, what you're doing is sort of like if you're raving about the beach, and I say I don't like bright sun, and you insist I need to try the beach to have an opinion on if I like it or not.
    - sodapopcan 7mo ago
      I wouldn't call "work" social interaction but I get ya. It's my biggest pet peeve of this industry: it has a whole lot of people who just don't want to talk to anyone. It is what it is, though.
      - palmotea 7mo ago
        > I wouldn't call "work" social interaction but I get ya. IMHO, social interaction is anything where you interact with other people. > It's my biggest pet peeve of this industry: it has a whole lot of people who just don't want to talk to anyone. That's very black and white thinking. I like talking to other people, but too much of it is draining. Every day spending all-day or even a half-day working directly with someone else? No thanks.
sodapopcan 7mo ago
I agree. The main reason people give for not liking it is that they say _they_ find it exhausting. _Everyone_ finds it exhausting, at least at first. That mostly stops being the case after a while, though. It can still be tiring but it found it to be a good kind of tiring because we were getting so much done. The team I used to pair on worked incredibly quickly that we started doing 7 hour days and no one noticed (although eventually we came clean). I find it depressing and dystopian that people are now excited about having a robot pair.

iampims 7mo ago

I’ve started pair programming with Claude and it’s been pretty fun. We make a plan together, I type the code and Claude reviews it. Then we switch.

lelandfe 7mo ago
You’ve made the analogy but I don’t think you’re actually doing an analogous thing. I think you’re just talking about code review.

alkonaut 7mo ago

The problem is that you can only meaningfully pair program with programmers. The people involved in architexture/design meetings might not be programmers. The questions that arise when 2 programmers work might not be resolvable without involving the others.

pydry 7mo ago
Nonsense. I pair all the time with stakeholders. If you strip out all of the cucumber nonsense this is essentially what BDD is - fleshing out and refining specs by guiding people through concrete, written example scenarios. I also often pair with infrastructure people on solving a problem - e.g. "im trying to do x as per the docs, but if you look at my screen i get an 1003 error code any idea what went wrong?". Or, people on a different team whose microservice talks to mine when debugging an issue or fleshing out an API spec. It's true that this isnt possible in plenty of organizations due to the culture, but lots of organizations are broken in all sorts of ways that set piles of cash on fire. This one isnt unique.
- deleted 7mo ago
  [deleted]
- nomel 7mo ago
  you're missing the context of this thread. for the purpose of code quality/review, it can only work if the other person is a programmer.
  - pydry 7mo ago
    I interpreted what they meant as "pairing doesnt work with non coders doing non coding design/architecture/requirements". Not "pair programming doesnt work with non programmers doing pure programming" coz it doesnt make much sense why you'd even attempt to do that. They dont care and they will get in the way.

lostdog 7mo ago

Maybe it's time to do pair agentic engineering? Have two engineers at the screen, writing the prompts together, and deciding how to verify the results.