1. 17

  2. 5

    The not use headphones link appears to be broken (moderator removed post on programmers.stackexchange.com).

    Here’s a working archive.org link: http://web.archive.org/web/20150511155104/http://programmers.stackexchange.com/questions/97917/my-company-wont-let-me-listen-to-music-anymore

    1. 3

      That’s kind of great. It’s certainly a familiar subject, but that’s an enormous amount of rigor.

      Not that it’ll change anything. :) Though I think a lot of the author’s point was that interruptions aren’t going away, so we should find technical solutions rather than social ones.

      1. 3

        Though I think a lot of the author’s point was that interruptions aren’t going away, so we should find technical solutions rather than social ones.

        I don’t think that a zero-interruption environment is practical but I think that the quantity and type of interruptions should be lowered. The idea that programmers should be available at all times is ridiculous. Real offices, a tolerance for asynchronous availability except in true emergency, and a better social status for people making software would be a start.

        As for finding technical rather than social solutions, that’s the problem with us as programmers. We’ve managed our social status so poorly that most of us are just business subordinates, working on Scrum tickets in cramped open-plan offices where getting anything done pretty much requires working off-hours in addition to the mandatory 10-to-6. We’re not going to fix this with better type systems and web frameworks, as much as those tools are enjoyable. We have to understand the politics if we want to replace the current reality with one where for programmers to work in engineer-driven companies is (as it should be) the norm.

        1. 2

          Agreed, on all of that. (And it reminds me of how lucky I am to work where I do…)

          You kind of said this implicitly, but it’s important to remember - managing our social status is up to us. It’s not a thing non-engineers are going to bestow on engineers if they don’t have to. I personally find this a bit difficult to even get started on, but it’s important. Ultimately the way that most of us have probably eventually found is to leave employers who don’t treat us with respect, in search of ones who do, but there really ought to be things short of that.

      2. 1

        “one person in a pair can hold the context while the other person in the pair gets interrupted. We could get back to work in seconds.”

        (Comment by James Grenning)

        I totally agree with this.

        1. 3

          I have to disagree, strongly. Pair programming as an 8-hour-per-day pattern is a terrible idea. It’s good to pair occasionally when it’s useful, but it shouldn’t be the default. After about 2 hours, it starts to burn people out and, as they tire, the “passenger” turns into a nonparticipant anyway. As a constant arrangement, it’s just another way for MBA-culture colonizers to shove mandatory extroversion (open-plan offices!) down programmers' throats.

          Also, environments that expect programmers to be constantly available are inherently broken and founded on culturally harmful assumptions (that programmers are low-status peons who can be expected to be available, and evaluated on their pliability, because they aren’t doing anything important). I might be completely wrong here, but it sounds like you’re trying to save “Agile”/open-plan culture and it isn’t worth saving. I don’t want to “get back to work in seconds” when pinged for an impromptu status update or context switch; I want a level of respect that makes them not happen (except in emergencies, of course).

          1. 2

            I’m pretty enthusiastic about pair programming, but I don’t think you can do it more than about 5 hours per day, and reaching that level requires constant attention to fatigue, hunger, and your partner’s feelings; and it also almost certainly requires switching pairs at least once a day.

            1. 1

              Fair enough. To make it clear, I think that pairing to solve a specific objective is a good thing. Making software environments more collaborative in general is also good. When two or more programmers realize that the most efficient way to achieve a specific task is to set aside time and pair, that’s exactly what they should do.

              I don’t like mandatory or permanent pair programming, because people often get their best work done alone, and I especially don’t like the idea that pair programming should be used as a patch to allow business people to treat us badly because one person can take the silly interrupt and the other, supposedly, can hold the context. That’s an unrealistic expectation, first of all, because the other person’s going to want to know about the Political Event That Just Happened; secondly, we should really be focused on getting our status to a point where we’re not interrupted over executive nice-to-haves, but only when the business situation absolutely requires it and we can “save the day”. One hopes, of course, that the number of days that need saving is small.

              1. 1

                I think there are some kinds of work that are best done alone, and other kinds that are best done in pairs.

                I’m glad I’ve never worked in the kind of workplace you’re talking about.

          2. 1

            It would be great to see that studied like the other topics in the article. I’ve only liked pair programming for knowledge transfer, but if reducing interruption cost is a replicable effect of pairing that’d be great evidence for its value. Fingers crossed some researcher takes it up. :)

            1. 1

              Subjectively, I think pairing does reduce my distractibility a lot. Like, my focus with pairing and my focus without pairing are not even in the same ballpark. It’s not because one member of the pair takes the distraction while the other sits there meditating, though. It’s because I don’t read Lobsters or listen to the conversation in the other room when I’m working to communicate with my pair; it might also be because third parties are more reluctant to interrupt our conversation than they would be to talk to one of us alone.

              For many people, the biggest benefit of pairing may be knowledge transfer, instant code review, uniform coding standards, or bringing to bear a greater diversity of experience on the problem at hand. For me, it’s focus, by a mile.