I don’t really enjoy pair programming. I like pair “thinking” (if that’s a correct term). I like to think about a problem and the design space with others… but writing actual code with others doesn’t really appeal me. It’s like 2 people painting in the same canvas parts of the same picture; it’s not gonna look pretty.
Pair programming can be great when applied selectively, as needed for short bursts on specific problems.
Pair programming when enforced full-time as a way of having two developers work together is completely exhausting, unpopular with most developers, and slower than having everyone work on their own problems. There is a certain personality who really likes full-time pair programming because they are very social and like coworking problems, but most people dislike it.
>> slower than having everyone work on their own problems
That’s fascinating, i recognise every bit of everything else you said but in my experience this was the golden redeeming quality - velocity of correct code is massively (maybe 4x) sped up.
Maybe the difference is overall - pairing becomes too tiring so you might be extremely productive but the short periods of it mean that the slow and steady solo approach wins out because you can do it for longer.
Pair programming if done on task such as "let's make this completely standard thing we've done five times already and need a slight variation of" is horrible. When working with new developers, if they're senior or junior, is great though. It doesn't have to be full days but a few hours a day of pair programming brings someone up to speed incredibly quickly.
When there's hard problems to track down, I think all developers go to pair debugging. If not only for the rubber duck effect.
Ha, humorously, I like pair debugging even less than pair programming. I need to think deeply when debugging a thorny issue, and I can't do that while interspersing communication.
I quite like "pair debugging". As someone that doesn't really like using a debugger, it's good to have someone that does use it to go through code (possibly not mine) with me commenting or suggesting problems. Probably irritates the heck out of the co-debugger though!
As a person who really enjoys debugging including (but not limited to) using a debugger: Yep, I'd rather do this myself than have to keep a mental channel open to listen to your comments and suggestions.
With more junior devs, I usually solve a problem together with them but I'm in the driver's seat. The best opportunity is when they come to your with a question. Just dive right into the code with them (this also shows them that it's "safe" to come to you with questions). It's so easy now with Slack and Zoom to ad-hoc jump into a session.
I'll talk out loud to myself and verbalize my thought process.
The objective is to show them tools, techniques, and approaches that they would otherwise not pick up. I'm not literally coding with them; I'm doing the coding and explaining my inner monologue for a given problem.
Tooling in particular can be hard to pick up. Even little things like the JavaScript debug console in VS Code can be a productivity changer.
For me, this has been very successful and I have helped more junior devs accelerate their careers. A lot of it is honestly selfish; the more I teach them to work and think like me, the more of my work I can hand off to them. In exchange, I get to work on more interesting things -- win-win
imo, the more senior counterpart benefits less from pair programming and therefore enjoys less. however, it's still the fastest way to get someone familiarized with a concept/project when done correctly. might be really valuable in a cs curriculum.
That doesn't sound like any pair programming I've ever done. There's always one person who writes the actual code and the other is there to think along, spot any bugs and discuss any better ways to do what we're doing (covering the rubber duck angle too). And then swap when the other one has a better idea on how to do something.
People always analogize this, but I've found "pair programming" with LLMs to be extremely underwhelming. I've tried it with Aider+Claude, Copilot Chat, 4o and o1, and the experience is always the same: I spend most of the time correcting misunderstandings before eventually giving up and doing it myself.
To this day I haven't found an LLM application that works better than regular autocomplete Copilot. It's sufficient to get over the blank canvas problem in a lot of cases without being overly ambitious and biting off more than the LLM can chew.
I've yet to try Cursor, but that's because I don't have a lot of hope: I first heard the same kinds of great things about Aider and Claude and o1, and all of those have disappointed. It's hard to want to switch editors to see if this time is for real.
I used Copilot and dropped it when it stopped being free. But Cursor is a different beast - the autocomplete is far better and intuitive. The chat functions like a personal StackOverflow (or just paste an error message for debugging).
For me as a senior eng, Cursor is where AI turned the corner from "maybe helpful for fringe / basic things" to "actually amplifies my productivity". Took about 30 min to flip the switch for me, so I suggest you give it a try.
The trouble is that I heard all of this—personal stack overflow, error messages—already with Claude, and I'm skeptical that anything Cursor can do on top of that will be worth losing the productivity of the JetBrains IDEs.
I imagine it's easier to switch for someone who's already making do with VS Code, because at that point the main hurdle is just being willing to pay for an editor. I already pay for an editor (a bundle of them), but "VS Code with better AI integration" just... doesn't appeal, especially when the word-of-mouth recommendations say all the same things that I've already heard about other tools that didn't work for me.
I had the perfect use-case for LLM-assisted coding a few days ago: I had a well-defined function to implement, for which dynamic programming was a great fit. I haven't used DP in years but it's a well-trodden path, why not throw the problem at the LLM and let it implement it?
Well despite careful prompting, it kept getting it wrong. At some point it generated some credible code, but I spent the day finding problems, nudging it to fix it, asking for explanations for stuff that looked (and was) incorrrect... Resulting code was bug riddled and horrible (LLMs tend to fix problems by adding more code rather than rearchitecting the existing code to eliminate edge-cases). I ended up spending a whole lot more time, I had to spend ages carefully nudging the LLM to no avail, understand LLM-generated garbage code _and_ still solve the problem myself.
