Related: https://twitter.com/mattrickard/status/1492548554426048514?s...
Not exactly a great attitude, but it’s how I came across the post.
Against Pair Programming
21–30 of 180 posts
Re: Against Pair Programming
#22Pair programming can be powerful with the right people and the right problem. It's a situational tool that can speed up progress in certain cases. Sometimes diving deeply into code is scary and having someone else right there can provide a feeling of safety that's conducive to making real progress. Also, sometimes programmers can have complimentary skills that can help them solve hard problems together on the spot. Pair programming sessions with the right people can also be intensely productive - people sometimes perform at a higher level when they're being watched. I've had very productive 3 hour coding sessions with team mates.
What I don't like is weekly or recurring pair programming sessions. That's always a bad idea. Pair programming is a powerful tool but should be used judiciously and situationally.
Re: Against Pair Programming
#23[deleted]
Re: Against Pair Programming
#24One of the things I believe the author is missing is flow efficiency vs resource efficiency. To reduce handoff and waste, sometimes the utilisation of a single resource may go down.
Re: Against Pair Programming
#25Pairing with rotation results in a situation where everyone on the team is familiar with all the parts of the system. Apart from the bus problem, which is rather low-risk, it means that you don't have to wait for the expert in subsystem X to have finished what he's doing and move to the new task; everyone's a subsystem X expert.
I don't think it's always worth pairing. Easy work that doesn't need expertise is best done solo.
I acknowledge the "velocity" accusation; I've never seen a pair work faster than two skilled solo developers. But the quality of the output from a pair is generally a lot higher than that from a solo coder. It really does help to have someone looking over your shoulder. I've not seen a comparison of solo and pair velocity that takes into account code quality, and debugging and bug-fixing effort.
Re: Against Pair Programming
#26Two keyboards, not one. As obvious as two chairs.
Re: Against Pair Programming
#27I've only used it once in my career, and at the time I was 'junior' to the other dev with the tools being used on a particular project (I was more senior/experienced than him overall though and had more produce expertise).
Did it for a long week (about 80 hours actually) when we were under a very tight timeline to get a product out the door - I actually thought it was extremely effective and productive - gained months worth of learning in a very short timeframe.
On the other hand, no way would I want to work someplace where it was assumed you would pair with someone all day every day.
Re: Against Pair Programming
#28It depends on the people. Dean and Ghemawat at Google are so used to coding together that Wired wrote about them as if they are one person (hence hyphenated double name in the title): https://www.wired.com/dean-and-ghemawat/
I can see where the author is coming from, but I have also had a few good pair programming sessions.
Pair programming where one is more of a mentee instead of a reviewer should be useful to upskill the mentee so the pair are at more similar levels.
Re: Against Pair Programming
#29Pair programming easily achieves the >2x speed boost though. The driver focuses on the technical details of writing high-quality code, implementation, proper variable naming and so on whilst the navigator keeps track of the overall task, provides extra short-term memory, spots silly mistakes/typos, focuses on business logic etc. So instead of one programmer juggling too much and stalling, getting bored/frustrated, lo…
Developers being unable maintaining both business logic and technical details in head at the same time are usually not hired. Actually this is their stated job description most of the time, translate logic into implementation. If this gives frustration probably better to look for some other occupation. Myself I actually enjoy this quite a bit. For avoiding and catching mistakes is useful but not a guarantee at all especially as their way of thinking is synchronised. There are other techniques for these as well (tools, patterns, reviews, ...) allowing two people working with two things.
Shared knowledge of a codebase is pretty useful. While it lasts. Also pitty it involves exactly 2 persons only. Documentation is far more reliable way of sharing code knowledge, especially long term and in changing team composition.
Re: Against Pair Programming
#30I recently took a junior role working on a decades old legacy codebase, in which all developers and almost everyone who had touched the code had quit in the previous year. The week I joined, the most experienced remaining developer put in his 2 weeks notice, after a 9 month tenure. The next most experienced had only been there a month or two.
We then spent every day of the next 2 weeks on near 8 hour videocalls developing some remaining features on his plate. It was an extremely effective knowledge transfer process. I learned plenty about this bizarre program and it's nonsensical logic, able to figure out future problems, and ended up as one of the main bits of glue keeping it all from collapsing. I also found it very rewarding to work that closely with a more senior developer, got a bunch of more general advice, had some interesting tangential discussions, and made a friend. Also got plenty of advice to leave the shitty company and it's terrible software asap.
I dunno if I'd want pair programming day to day, but it was a great experience at the time, and made my entry to the role much smoother than anyone elses.
The irony is, this guy hated the needless difficulties of the job, but was so happy about quitting that he made my onboarding pretty great, and so I didn't feel his level of frustration while continuing on in it.