Hacker News Reader

Comment by lucasnemeth | Hacker News Reader

I believe another reason to not pointing out the flaws come from mob thinking. It becomes very hard to criticize "the collective".

And yes, I think you have a great point on Biggest personality wins, that is already a problem on meetings. Lot's of amazing developers I've worked with had a hard time speaking in meetings...

View on HN

I agree that the personalities have to be all fairly extroverted for both mob and pair programming. However, as a counterpoint to it becoming hard to criticize "the collective" I've experienced that at least with pair programming the opposite trends to happen. No one had a sense of personal code ownership, so no one gets too attached to a particular implementation or feels personally criticized when criticizing code. My expectation would be that that would happen even less when mob programming. I wonder though what would happen if you had multiple mobs that never rotate team members. I could see that that might quickly escalate to a us vs them situation.

I wonder if you could set up a round robin programming order. Something like switching which is typing every day. So like whole team puts input while one person types, then delegate one person to drive the discussion. I don't know if that would help much though or just put it back into pair programming with extra overhead.

(Author here) We do round robin for keyboard input, but a lot more often than that. We try to switch a couple of times each hour.

We do not have a particular person driving the discussion though, I do not see that that would help us in any particular way.

In my limited experience pair programming it usually went like, "How about if we combined these and frobbed before...aww, let me drive and I'll show you." Who had the keyboard might stay the same for hours, or might switch every 15 minutes, depending.

Or just plug in several usb keyboards and mice into one computer so everyone can type without switching chairs or handing the keyboard over.

From the photos it does look like they did just that.

that souInd s Hatlikee tthahtat a good idea.

The person typing should not be driving. It's a bit hard to get to that point and we fail it a lot of times, but as a general rule the person sitting at the keyboard tries not to drive.

Also, if you are not the person currently at the keyboard, you are not allowed to just take over. We used strict time boxes at first to make sure that this didn't happen, these days we are a bit more relaxed since it isn't really an issue anymore.

Yeah, well, we did a lot of things our own way. We tried some things. Some of them stuck, some of them we adapted to suit us, and other things we dropped.

> The person typing should not be driving.

What's the reasoning behind this? My guess is that it's to prevent pair programming from turning into lone programming with an observer. If that's the case it wasn't a problem for our specific situation. No matter who had the keyboard, there was collaboration. Why separate the keyboard from the person who can fastest/best get the code on screen for consideration?

> Also, if you are not the person currently at the keyboard, you are not allowed to just take over. We used strict time boxes at first to make sure that this didn't happen

Why? Of course you shouldn't snatch the keyboard out of someone's hands, but such behavior should be addressed in other ways than by making rules. I suspect it's not that, but something else. Even so, I have to wonder if it's a social issue that would still be better addressed in other ways than by imposing rigid structure.

Anyway, switching when we wanted did not seem to pose any problems. If we missed out on some benefits then I'd like to know about them.

Reply on news.ycombinator.com