4 ms·

That's such a mechanical way of describing pair programming. I'm guessing you don't do it often (understandable if its not working for you). For me pair progra

by yarekt 2y ago

That's such a mechanical way of describing pair programming. I'm guessing you don't do it often (understandable if its not working for you). For me pair programming accelerates development to much more than 2x. Over time the two of you figure out how to use each other's strengths, and as both of you immerse yourself in the same context you begin to understand what's needed without speaking every bit of syntax between each other. In best cases as a driver you end up producing high quality on the first pass, because you know that your partner will immediately catch anything that doesn't look right. You also go fast because you can sometimes skim over complexities letting your partner think ahead and share that context load. I'll leave readers to find all the caveats here Edit: I should probably mention why I think Chat Interface for AI is not working like Pair programming: As much as it may fake it, AI isn't learning anything while you're chatting to it. Its pointless to argue your case or discuss architectural approaches. An approach that yields better results with Chat AI is to just edit/expand your original prompt. It also feels less like a waste of time. With Pair programming, you may chat upfront, but you won't reach that shared understanding until you start trying to implement something. For now Chat AI has no shared understanding, just "what I asked you to do" thing, and that's not good enough.

RHSeeger 2y ago
I think it depends heavily on the people. I've done pair programming at a previous job and I hated it. It wound up being a lot slower overall. For me, there's - Time when I want to discuss the approach and/or code to something (someone being there is a requirement) - Time when I want to rubber duck, and put things to words (someone being there doesn't hurt, but it doesn't help) - Time when I want to write code that implements things, which may be based on the output of one of the above That last bucket of time is generally greatly hampered by having someone else there and needing to interact with them. Being able to separate them (having people there for the first one or two, but not the third) is, for me, optimal.
- Tempest1981 2y ago
  You could try setting some quiet hours. Or headphones. Maybe collaborate the first hour each morning, then the first hour after lunch.
  - _w1tm 2y ago
    I think you missed the point. AI chat is not compatible with the solitary focused programming session.
ionwake 2y ago
this is so far removed from anything I have ever heard or experienced. But I know not everyone is the same and it is refreshing to view this comment.
freehorse 2y ago
Pair programming is imo great when there is some sort of complementarity between the programmers. It may or may not accelerate output, but it can definitely accelerate learning which is often harder. But as you say, this is not what working with llms is about.
taneq 2y ago
> As much as it may fake it, AI isn't learning anything while you're chatting to it. What's your definition of 'learn'? An LLM absolutely does extract and store information from its context. Sure, it's only short term memory and it's gone the next session, but within the session it's still learning. I like your suggestion to update your original prompt instead of continuing the conversation.
- yarekt 2y ago
  When working together with a colleague, after some weeks each of you understand more how the other works, what they need to be productive, how to communicate better and achieve good results. Same with the domain context you’re working on, as your mental model grows more detailed, your performance goes up. with LLMs that leaning is only context, and in case of “chat ai” is the chat backlog. It’s easy for the LLM to get stuck, and there aren’t many tools yet that help you change and morph that context to be more like shared understanding between two colleagues. There is research going on in this area, eg “chain of thought”, so we’ll see, maybe things will get better
skue 2y ago
> I'm guessing you don't do it often (understandable if its not working for you). For me pair programming accelerates development to much more than 2x. The value of pair programming is inversely proportional to the expertise of the participant. Junior devs who pair with senior devs get a lot out of it, senior devs not so much. GP is probably a more experienced dev, whereas you are the type of dev who says things like “I’m guessing that you…”.
- balp 2y ago
  As a senior dev, when pairing with junious I get a more skilled team. Then I can continue to give new teams the skill and we all grow as people and companies.
- kybernetikos 2y ago
  I don't agree with this at all. Pairing where there's a big skill gap isn't proper pairing, it's more like mentoring or hands on training. In pair programming as I learned it and as I have occasionally experienced it, two individuals challenge each other to be their best selves while also handing off tasks that break flow so that the pair as a whole is in constant flow. When it works this is a fantastic, productive, intense experience. I would agree that it is more than 2x as productive. I don't believe it's possible to achieve this state at all with a mismatched pair. If this is the experience people have in mind, then it's not surprising that they think that those who think it's only for training juniors haven't actually tried it very much.
  - yarekt 2y ago
    Exactly this. And I did mean equal skill when i said “more than 2x” implying that you get more done together than if you were separate. One interesting thing is skill levels aren’t really comparable or equatable. I find pairing is productive where skills only partially overlap, meaning the authority on parts of implementation flows between participants, depending on the area you’re in. I have some examples where I recently paired with a colleague for about 2-3 weeks nearly every day. i’m confident that what took us a month would be near impossible just working on our own
viraptor 2y ago
> but you won't reach that shared understanding until you start trying to implement something. That's very much not my experience. Pairing on design and diagrams is as or more useful than on the code itself. Once you have a good design, the code is pretty simple.
dkkergoog 2y ago
[dead]

by yarekt 2y ago

RHSeeger 2y ago

I think it depends heavily on the people. I've done pair programming at a previous job and I hated it. It wound up being a lot slower overall. For me, there's - Time when I want to discuss the approach and/or code to something (someone being there is a requirement) - Time when I want to rubber duck, and put things to words (someone being there doesn't hurt, but it doesn't help) - Time when I want to write code that implements things, which may be based on the output of one of the above That last bucket of time is generally greatly hampered by having someone else there and needing to interact with them. Being able to separate them (having people there for the first one or two, but not the third) is, for me, optimal.

Tempest1981 2y ago
You could try setting some quiet hours. Or headphones. Maybe collaborate the first hour each morning, then the first hour after lunch.
- _w1tm 2y ago
  I think you missed the point. AI chat is not compatible with the solitary focused programming session.

ionwake 2y ago

this is so far removed from anything I have ever heard or experienced. But I know not everyone is the same and it is refreshing to view this comment.

freehorse 2y ago

Pair programming is imo great when there is some sort of complementarity between the programmers. It may or may not accelerate output, but it can definitely accelerate learning which is often harder. But as you say, this is not what working with llms is about.

taneq 2y ago

> As much as it may fake it, AI isn't learning anything while you're chatting to it. What's your definition of 'learn'? An LLM absolutely does extract and store information from its context. Sure, it's only short term memory and it's gone the next session, but within the session it's still learning. I like your suggestion to update your original prompt instead of continuing the conversation.

yarekt 2y ago
When working together with a colleague, after some weeks each of you understand more how the other works, what they need to be productive, how to communicate better and achieve good results. Same with the domain context you’re working on, as your mental model grows more detailed, your performance goes up. with LLMs that leaning is only context, and in case of “chat ai” is the chat backlog. It’s easy for the LLM to get stuck, and there aren’t many tools yet that help you change and morph that context to be more like shared understanding between two colleagues. There is research going on in this area, eg “chain of thought”, so we’ll see, maybe things will get better

skue 2y ago

> I'm guessing you don't do it often (understandable if its not working for you). For me pair programming accelerates development to much more than 2x. The value of pair programming is inversely proportional to the expertise of the participant. Junior devs who pair with senior devs get a lot out of it, senior devs not so much. GP is probably a more experienced dev, whereas you are the type of dev who says things like “I’m guessing that you…”.

balp 2y ago
As a senior dev, when pairing with junious I get a more skilled team. Then I can continue to give new teams the skill and we all grow as people and companies.
kybernetikos 2y ago
I don't agree with this at all. Pairing where there's a big skill gap isn't proper pairing, it's more like mentoring or hands on training. In pair programming as I learned it and as I have occasionally experienced it, two individuals challenge each other to be their best selves while also handing off tasks that break flow so that the pair as a whole is in constant flow. When it works this is a fantastic, productive, intense experience. I would agree that it is more than 2x as productive. I don't believe it's possible to achieve this state at all with a mismatched pair. If this is the experience people have in mind, then it's not surprising that they think that those who think it's only for training juniors haven't actually tried it very much.
- yarekt 2y ago
  Exactly this. And I did mean equal skill when i said “more than 2x” implying that you get more done together than if you were separate. One interesting thing is skill levels aren’t really comparable or equatable. I find pairing is productive where skills only partially overlap, meaning the authority on parts of implementation flows between participants, depending on the area you’re in. I have some examples where I recently paired with a colleague for about 2-3 weeks nearly every day. i’m confident that what took us a month would be near impossible just working on our own

viraptor 2y ago

> but you won't reach that shared understanding until you start trying to implement something. That's very much not my experience. Pairing on design and diagrams is as or more useful than on the code itself. Once you have a good design, the code is pretty simple.

dkkergoog 2y ago

[dead]