3 ms·
Ding, ding, ding. I find it funny most people don't realize pair programming is about control. It's like a workplace Stasi. Management expects you to deal with
by alteredbeats 6y ago
Ding, ding, ding.
I find it funny most people don't realize pair programming is about control. It's like a workplace Stasi. Management expects you to deal with the inevitable conflict resolution, even if that's not your job. Even if your pair shows only for a couple of hours a day and you have to do the work of two people.
“Much harder to spend time on HN” people who like pair programming either like to have power over someone else, or they want to coast and/or be handheld.
People say it's about collaboration... it's more about learning power phrases like “let’s timebox this exploration”, “you have to call the keyboard”, “let’s do plus and deltas”.
I tolerate it because the productivity is so low it helps recovering workaholics.
It's the best secret to dilute accountability and charge outrageous consulting fees.
- thinkingemote 6y agoIf it is like workplace Stasi and like the movie Brasil, shouldn't we expect pairs to slack off together in conspiracy, watching movies like in Brasil or commenting on HN instead of working. Does pair programming cause dysfunction? Also, is there a pair programming equivalent of the Scrum Master? That would be the chief slack position.
- michael1999 6y agoNo. That's one of the many differences between Scrum and XP. XP is the feral cousin of Scrum.
- denton-scratch 6y agoI liked pairing. I was pairing for about three years, 09:30 to 17:00, with an hour for lunch. It certainly is exhausting. It certainly produces better code. If you pair and rotate, then after a number cycles, everyone in the team knows the codebase. There is something a bit weird about XP. It looks as if coders are being given control, and they are; but they manage themselves even more sternly than their management would have. That is, coders seem to demand more of themselves than even aggressive managers. Everyone knowing the codebase is also a way for developers to shoot themselves in the foot; when everyone knows your job, it becomes easier for you to be replaced. I'm not a master programmer - at best, I was a journeyman. I learned a lot from the people I paired with, about half of whom were better than me. I only paired with two guys that I found really difficult; one was a good programmer, but had quite severe asperger's. The other was a reckless, entitled idiot, and pairing with him amounted to trying to stop him writing any code. I'm not familiar with those "power-phrases". And I never encountered power games. I guess we all had enough confidence in ourselves and our colleagues that we didn't feel we had to prove anything. We respected one-another. Well, I certainly respected (most of) the other team members. In a disfunctional team, I guess pairing can only make things worse. Regarding diluted accountability: I found the oppposite. At the morning SCRUM, you have to give an account of what you did yesterday. You can't make it up, because your pair is at the SCRUM too. And the evidence is in the commit log. And I didn't find that productivity was low. I'd say that functionality was delivered at about 75% the velocity of solo work, but the code we delivered was much better quality, so maintenance and bug-fixing was massively reduced. I was working with a team of rather good people; I imagine pairing might be a lot more tedious and unproductive if the majority of the team are dim, incompetent, socially maladapted, or psychopathic. But then the same applies to solo coding. I don't know what a "Pivot" is.
- hibbelig 6y ago> People say it's about collaboration... it's more about learning power phrases like “let’s timebox this exploration”, “you have to call the keyboard”, “let’s do plus and deltas”. I sense that you might be saying those phrases can be used to manipulate the other half of the pair. For the first one, I can speculate: The pair disagrees how to approach some problem, then one of the two suggests to “timebox an exploration” into their favorite approach, and then after spending an hour on it (or whatever), the code is already there and nobody wants to delete it again. But what do the other two phrases even mean, and how would they be used to manipulate?