| 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... > |
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