2 ms·
I’m interested in the last one, specifically pair programming. I think we’ve lost a lot of serendipitous communal wisdom with remote work, and meetings don’t he
by jl2718 4y ago
I’m interested in the last one, specifically pair programming. I think we’ve lost a lot of serendipitous communal wisdom with remote work, and meetings don’t help. Does anyone have experience with pair programming helping with this, or does it always just feel like another long pointless meeting where everything gets done independently later? I would really like to find the best way to do this.
- npinsker 4y agoI know people that love it, but my experience has been that it usually feels like an inefficient use of time. I mostly agree with https://matt-rickard.com/against-pair-programming/ https://matt-rickard.com/against-pair-programming/ on the same site, especially this bit: 'For existing employees, pairs are often stuck at the speed of the least senior pair.' It has a few powerful but niche use cases, particularly around mentorship (where I think asynchronous feedback is often too little, too late) and when two people are doing work that's closely intertwined.
- MonkeyMalarky 4y agoPair programming has become 100x better after going fully remote. The context under which it is happening matters a ton though. Doing a meeting that's the equivalent of a PR review session with multiple peers lobbing all sorts of random unfiltered criticism your way, in real time, sucks hard and you shouldn't do that. But pair programming that is spur of the moment where one party says "hey I have this predicament", "what do you think about doing X like this" or "can you help me debug something" and you smash out a solution together in an afternoon is great.
- iratewizard 4y agoI've found from a management position it's a useful tool to confirm suspicions about salary thieves. Sometimes I pair them with a no-nonsense dev who will tell me specific problems. Sometimes I pair two problem developers together and see if the pressure of another person makes them build properly. Mostly, though, pair programming is my favorite way to get people up to speed with a project and to prevent information silos about critical functionality. My devs do them about once a quarter with each other for a week or as needed.