1. 18

This resonated with me personally:

We are no longer a culture that respects silence. The extroverts have won. Everything must be done collaboratively. Everyone must be available to everyone, all the time. There should be no more personal space, and no ownership of work. Basically, we believe that two heads are always better than one.

I currently work in a pair-programming exclusive company, and after a year and a half I’ve decided that no amount of forcing it will cause me to like it.

  1.  

  2. 16

    Forced collaboration is counter-productive almost always.

    Two observations on this. First, there’s a spectrum between the introverted and extroverted approaches to work, and most people do best in the middle. At Bell Labs, people who had their doors open were less productive in the short term, but more productive in the long term, than those whose doors were always closed. You get more done per hour, perhaps, when your door is closed, but it’s important to know what others are working on and where fruitful results might be found. Of course, the software industry has swung the pendulum to the other extreme, with these open-plan offices (cough back-door age discrimination) where it’s impossible to get anything done. It seems that the only think that open-plan startup offices/cultures generate are sexual harassment claims, and I think that we’d all agree that those are net negative.

    Having the option to retreat into a silent space is important. That said, practical research is often more of a team sport than an individual one. Actually, this is even true in theoretical pursuits like pure math. Otherwise, the concept of the Erdos Number wouldn’t have much meaning. Of course, all of this collaboration is organic and voluntary, and that ought to be the key observation.

    Second, the software industry has some terrible people in it, especially at the executive ranks. Why is this relevant? Because the evildoers don’t want programmers to be more productive, but more replaceable. Hence, the drive to turn software engineering, which used to have an R&D flavor, into ticket-shop Scrum work where non-technical people called “stake holders” (presumably because programmers are vampires) call the shots. The culture where (to use OP’s on-the-mark words) “Everyone must be available to everyone, all the time,” isn’t about productivity but about exerting a fascist degree of control. And, of course, a malevolent manager striving to turn programmers into fungible commodity workers would want a culture where there’s (again, using OP’s on-the-mark phrasing) “no ownership of work”. Not all of that is an accidental accommodation of extroverts; some of it’s malicious.

    The problem, in dealing with management practices like required pair programming, is that you have to know which sort of managerial impulse you’re dealing with. You might have the well-intended, benevolent manager who sees that pairing can have its uses, but who takes it too far and makes it 4 hours of pairing per day instead of 1-2. That requires a diplomatic approach. Or, you might have the malevolent manager who’s trying to make engineers replaceable, in which case the best option is probably to change jobs.

    1. 5

      I agree with you 100%.

      You might have the well-intended, benevolent manager who sees that pairing can have its uses, but who takes it too far and makes it 4 hours of pairing per day instead of 1-2. That requires a diplomatic approach.

      I pair-program 7 hours a day, 5 days a week. Not only that, we rotate once per week. It’s like it was designed to burn us out.

      Or, you might have the malevolent manager who’s trying to make engineers replaceable, in which case the best option is probably to change jobs.

      Yes, and yes

      1. 4

        I had the same “always pairing” situation and found it drained my skill and energy to the point that I was barely able to accomplish anything. I’ve recovered… but get out while you can.

        1. 4

          My last job had us pairing 7-8 hours per day with a pair switch every every 1-4 hours. There were other issues there as well, but the pairing was enough after 9 months to make me seriously consider leaving software alltogether.

          1. 4

            the pairing was enough after 9 months to make me seriously consider leaving software alltogether.

            You’d be in good company. “Agile” methodologies, forced pairing, and open-plan offices are a big part of why our industry seems to eject from the top, starting in the early 30s and finishing around 40.

            Pairing is sometimes useful but in limited doses. To me, forced, constant pairing suggests that management wants people to be constantly watched and is trying to set up a fuck-your-buddy system where slackers (real or perceived) get found and ratted by teammates, saving management the burden of actually, um, managing. “Agile” and everything-must-be-in-Jira work the same way: create a system where the team rats out its own people.

            The proletarianization of software engineering is both depressing and a bit dangerous to the survival of the industry. I’ve come to the conclusion that for corporate software engineering, the ghettoization is both harmless and inevitable. Line-of-business coding can afford to lose the over-30, top-5-percent programmers because it doesn’t need us in the first place. However, there’s a lot of software where correctness and performance actually matter, and driving out the most conscientious and knowledgable people is really, really bad. I have a friend at a company (details omitted) doing something that all of us would call “real technology” and the sloppy, Silicon Valley, Agile/Scrum approach is used even there… and, in that particular case, it could get people killed.

            Over the years I’ve come to the conclusions that business software is a lost cause. The culture of mediocrity and performance surveillance (which is necessary if you’re letting in cut-rate boot-camp grads with 3 weeks of training) is permanently entrenched and it won’t go away. The right move for us older, conscientious people is to go back into research and science, even if that means giving up the peak-bubble salaries, free dinners, and expensive holiday parties.

            1. 2

              I believe in the case of this team the constant pair switching and focus on hyper-local maxima was all about driving a hivemind. The constant pair switching amplified every single cultural clash, difference of opinion, of ideal, and ultimately drove out anyone who refused to conform. I came into the team with far more experience in some key areas of the project than anyone else on the team, and yet was completely blocked and unable to make any effective positive changes, even in the face of ample evidence that the existing approaches were failing. Rather than doing things the right way, they doubled down on pair switching more, as though it would increase the synaptic response of this siphonophoric team. This singular being was unable to comprehend an outsider, or act on advise that came from outside of it’s colony. The futility of trying to make even a modicum of progress on things that were just absolute garbage fire codebases, along with the rampant sexism that was amplified through the style of work, was just incredibly draining.

              All that said, there’s just too much compelling about software for me to be able to leave; I’ve gotten a new appreciation for what kinds of teams I won’t work for, and I’ve been invigorated to help try to teach and mentor people on better, less systemically toxic was of creating software.

              1. 1

                I believe in the case of this team the constant pair switching and focus on hyper-local maxima was all about driving a hivemind.

                A lot of “Agile” is a way for management to get programmers to rat each other out. The problem with hyper-literal people (like many engineers) is that they actually believe in objective job “performance” and that the people who are disengaged, ignored, or just unlucky are genuinely stupid, irredeemable people.

                For example, when Goldman Sachs rolled out a peer review system, salespeople and traders gave each other all top marks while engineers slammed each other. That shouldn’t be surprising. Only engineers would be hyper-literal/socially-stupid enough to believe that there could be any positive benefit in ratting each other out to management.

                The purpose of the constant “little brother” surveillance (constant, forced pairing with frequent changes of forced pairs) is to get to an arrangement where people feel pressured by each other to “perform” (cough conform) and management doesn’t have to do any work. This way, the business gets (in the short term) the most out of everyone while investing nothing in its employees.

                The futility of trying to make even a modicum of progress on things that were just absolute garbage fire codebases

                Yes, this style of management results in terrible code. It’s a disaster in the long term, but most software managers expect to be promoted away from the mess before that matters.

                along with the rampant sexism that was amplified through the style of work

                Oh yes. Most of us have no idea how much racism and sexism there is in these open-plan offices. I’m a white male so I don’t experience it, but I do something that most corporate software engineers don’t do, which is talk to people who are different from me.

                To an extent, it’s deliberate. I don’t know that the Powers That Be in your office (or in the typical software office) have any ideological love for sexism per se, but they’re all about divide-and-conquer tactics. Unfortunately, engineers tend to be very easy to play against each other.

                I think the reason is that all of them recognize the gap between their intellectual capability and the demands of the work– let’s be honest: corporate software isn’t that hard and any idiot can do it; and that’s not true of the math-heavy R&D work you were trained to do if you got a serious STEM degree– and therefore assume an implicit extreme superiority. They are correct in observing that they’re smarter than typical corporate software work demands they be; they are incorrect in believing that this matters or gives them an advantage. At any rate, this leads the hyper-literal/socially-gullible engineer to conclude, “I’m so much smarter than these idiots”, and that prevents anything like a union from forming.

      2. 4

        I’m a pretty strong introvert (I’m typing this comment at a conference as a way of avoiding talking to anyone) and I have, somewhat reluctantly, found pairing to have some benefits for me. I think it helps that (a) it’s not mandatory at my company, and (b) we are all remote (as is our pairing). Pairing feels like less of an imposition on my personal space when it’s done via headphones and a shared tmux session. I won’t claim that it’s the best approach for everyone, but I do think it can be compatible with introversion at least some of the time.

        1. 2

          I’ve worked in both environments. I see pair programming as more of a tooling question than a methodology. It’s like the IDE versus text editor question: if an IDE makes you more productive than a text editor, use an IDE.

          It’s the same with pair programming. I’m not a fan of pair programming but I’ve seen other developers excel at it. If it works for you, great! But don’t force the tool on all developers because it makes you more productive.[1]

          Some shops think PP ensures more than one developer knows the code base. That’s true to a point. Another option might be to focus on code hygiene and documentation. If you can afford to put two developers full time on every problem perhaps you can afford to let each developer spend 50% of their time on documentation.[2]

          Regarding the impact of open-door versus closed-door developers on productivity, I see that as orthogonal to PP. One developer behind a closed door knows as much or as little about what the rest of the team is doing as a pair behind a closed door. The key is emerging from behind the door and talking with the rest of the team. For many developers a company IRC server is the perfect solution. For others, weekly team lunch or daily stand-up.

          [1] I prefer to collaborate by talking through the occasional, knotty problem with another developer, typically on a whiteboard or over coffee. Rarely over a keyboard. (I really hate working on other developer’s keyboards when the CapsLock isn’t remapped to Ctrl. Nothing slows me down more than a keyboard not designed for my typing style.)

          [2] This is one of the reasons I prefer the BSDs (especially OpenBSD) to Linux. The base documentation is very good and useful for it’s intended purpose. It’s not just a check mark.

          1. 2

            I’ve never had to pair program for work, but I’ve been required to do it for a number of university classes.

            It’s very, very hard to find someone where I feel more productive than I am working alone. There’s an obvious problem with diminishing returns when you put more eyes on a screen, and in many cases it was actually a negative return right off the bat.

            You have to worry about scheduling, explaining your thoughts to the other person, bringing each other up to speed, bikeshedding, etc. Unless you’re both really on the same page, it’s going to suck. You’re probably going to get less work out than you would have if both were working separately, and possibly less work out than if just one of them was working alone.