4 ms·
I think he's a bit too "binary" in his estimation of others opinions on the matter. Personally I like pair/group programming about 1/4 of the time. Usually duri
by noonespecial 10y ago
I think he's a bit too "binary" in his estimation of others opinions on the matter. Personally I like pair/group programming about 1/4 of the time. Usually during the beginnings of a big project.
Its great for going "wide" but it sucks for going "deep". Use it when you need it. Don't when you don't.
Now I'll grant you that when you have a manager who likes the buzzword and insists on it dogmatically, you might have a problem on your hands.
- toomuchtodo 10y agoAgree entirely! I'm on a DevOps team, and I love pair programming with my boss for an hour or two a week when we're breaking ground on something new during a sprint. It's tedious when either of us are lost in the weeds, but it's damn helpful when we're fleshing out the rough structure, bouncing ideas off of each other. It's really just a step above whiteboarding now that I think of it.
- trowawee 10y agoI would say though that one benefit of pairing that I've definitely experienced is that it can keep you from chasing bad ideas down deep, pointless rabbit holes. A lot of the time, when I pair (usually informally), the other person sees something quickly that I missed, or questions some assumption I've been making that turns out to have been incorrect or misguided. If I'd had that input, I might have saved a hour or two running into dead ends. But I'm not sure what the best way to balance it would be - I would never want to do the Pivotal-style all-day every-day pairing, but it's hard to know when you could benefit from another set of eyes, especially when you're already deep into something. Maybe a morning-afternoon split on alternating days or something like that?