[mlthoughts2018]

I am not sure why it is astonishing to you. It’s been known for a long, long time that developers minimally need near total silence to do their jobs properly, and need privacy and space to think or diagram privately on a whiteboard, etc.

> “as they genuinely appear-to me-that many developers would be better served working at home where they can enjoy complete and total silence.”

Fully private offices are better, with a high degree of respect to not interrupt your colleagues. Working from home, as you suggest, is certainly much much better than working in an open-plan office though.

> “We seem to have moved beyond that and are now picking apart the very nature of working with and supporting your colleagues when they come to you for assistance, the idea that something as innocuous as a senior developer helping a junior developer being a problematic and prima facie distraction that must be snuffed out and I find that attitude completely untenable“

It’s hardly untenable. It’s a basic part of the job. What you glibly call “a senior developer helping a junior developer” is not that.

When I think of helping junior developers, something I do all the time, I think of using Slack or email to schedule a meeting to answer their questions at some point that’s convenient for us both, in a conference room where we won’t bother other people.

The culture of “just quickly answer my question right now” is horrible, productivity-killing nonsense, but here you’re acting like it’s the only possible way to work.

[dvtrn]

It’s been known for a long, long time that developers minimally need near total silence to do their jobs properly

According to whom? I've been a developer near 14 years now and have worked in siloed offices, cubicles, open office spaces, and my last job was 100% remote for two years. From what authority do you claim to draw the assertion that this is the case?

Anecdote is no replacement for quantitative sample sizes, but this statement seems too absolute to hold any validity without qualifying by whose standards you are suggesting that it has been known for a-as you put it-"long, long time".

What you glibly call “a senior developer helping a junior developer” is not that.

Glib? I'm sorry friend, but no. Absolutely not. Taking two minutes to help someone new on the job find answers periodically throughout the day, and wheeling my chair 180 degrees to render aid as the senior developer is not glib.

What's "glib" is this idea that I am somehow disrupting the workforce, and destroying productivity by preferring to talk to the person who literally sits three feet away from them to help solve a problem than smacking away at my keyboard to answer a question that takes the better part of 180 seconds were I to verbalize "Here's the solution you're looking for and how it fits in to the larger scheme of this feature we're working on". I've been on the other end of that, it felt cold and impersonal as a newbie, and I strive to be the kind of team leader I wanted when I was that junior developer.

The culture of “just quickly answer my question right now” is horrible, productivity-killing nonsense, but here you’re acting like it’s the only possible way to work.

Answering a question quickly is productivity-killing? Then how are you defining productivity, friend? If it's a question that has a short, sufficient and ultimately resolute answer that gets my junior developers the support and response they need to solve the challenges we face as a team, elongating that answer out to a long essay-diatribe is more killing to the productivity. If by that point we need more time, then-as I said in another comment-it absolutely is valid and worthwhile to say "Let's schedule some time to get into a conference room and whiteboard through the problem". Go look above this comment chain, I said as much pretty clearly.

And speaking of clearly? I really appreciate that you took this position and completely ignored the fact that I went through great effort to indicate that I prefer to speak directly to someone "within reason" and went as far as to suggest that when the person is sitting mere inches away from me, that is a scenario that I personally consider "within reason". That alone should have been a pretty clear indicator to you that no, I actually do NOT think that it's the only possible way to work, just a very effective one given the proximity to my cohort. I had hoped that the context clues would reveal themselves clearly, evidently and plainly. I see now that they did not.

I'm going to go ahead and take this time to leave the thread entirely, this debate stopped being fruitful a long time ago and I'm frustrated with myself that I spent as much time replying to it as I have.

Please do, if nothing else, have a wonderful weekend :) I'm sorry we disagree so strongly on this.

[mlthoughts2018]

Have you ever read Peopleware[0], particularly the chapter called “Bring Back the Door” and the various studies it cites about distractions in software engineering and effect on defect rates?

Note that this was written in 1987. And cites even earlier works on the topic. By now there’s been an explosion of research on this topic.

> “Glib? I'm sorry friend, but no. Absolutely not.“

Uhh, yes. You are being glib by making a certain phrase (“senior developer helping a junior developer”) have a twisted meaning (that it can only mean a real-time, interruptive audio interaction, rather than scheduled time to help). That’s glib because the short phrase “senior developer helping a junior developer” unpackages into a bunch of complicated factors that need to be considered, and a very important one is to not presume that an interruptive question is worth disrupting someone else’s work over in the moment. You glibly try to side-step this by acting like disrupting someone to ask for help is the primary option and that it’s de facto a good thing to encourage this type of disruptiveness by giving instant gratification with an immediate answer, but it’s not! Glib absolutely is the right way to describe how you are trying to sidestep the real, material meaning of what it is to help out a junior developer (which generally has nothing to do with answering their real-time audio questions in the moment they ask).

> “Answering a question quickly is productivity-killing? Then how are you defining productivity, friend?”

Yes, stopping what I am already working on in order to answer your question will kill my productivity by a lot in order to help your productivity only a little.

This is pretty simple stuff. Why are you unsure about it?

> “went as far as to suggest that when the person is sitting mere inches away from me, that is a scenario that I personally consider "within reason".”

But this is a harmful attitude on your part. It makes no difference if the person is sitting inches away from you. Why would you think physical proximity has any effect in this? What matters is whether the other person is deeply concentrating on something that they judge to be highly important to maintain focus on. Your point of view seems to be about your convenience and not the damage it would do the people who are distupted around you.

Your vitriolic reaction is very frustrating to process because you still do not seem to engage with the basic aspect of this whole topic, which is that if a question pops into your mind that affects you, that does not mean it is worth wasting someone else’s time over if they are busy. That is one of the fundamental problems of open plan offices that encourage ad hoc verbal communication, which is incompatible with modes of working that require extended concentration time for most hours of most days (e.g. almost all of software engineering).

[0]: < https://en.m.wikipedia.org/wiki/Peopleware:_Productive_Proje... >

[dvtrn]

>Yes, stopping what I am already working on in order to answer your question will kill my productivity by a lot in order to help your productivity only a little.

And yet AGAIN my initial post is misconstrued completely and entirely because people I guess just don't know how to read today.

I am not the person interrupting my coworkers. I am the one being interrupted and asked to help a junior dev. Read my darn post. Read it. READ IT. I am not interrupting my coworkers. I am a senior dev being asked for help. I am the one being interrupted. I am being asked to assist someone. Stop accusing me of breaking my coworkers flow. That is not what I said. That is not what I offered. That was not my post. That was not the position I argued. Those were not my words.

It's actually getting VERY frustrating having responses levied at me as if I am the person disrupting my coworkers, and not the person who is having his own workflow and concentration broken, and repeatedly having responses thrown at me as if I am the root cause of my coworkers not being productive.

/throws up hands

[mlthoughts2018]

You talked about your propensity to answer people right there in the midst of the open space, thus contributing to the noise. I’m discussing how a side-effect of that would be to distract many other people, and then also discussing the general problem of these interruptive questions (even though I understand your line of comments was about how you will answer questions, and it was misinterpreted in other threads).

The portion you quoted does not use the word “you” to specifically refer to you personally, but to the general phenomenon of either being interrupted when someone asks a question or being disrupted when people loudly discuss an answer to the question right where everyone is trying to work, instead of moving to a separate common area like the cafeteria or a conference room, or scheduling a meeting to go over it later when it won’t disrupt people.