In Search of Quietude

Learning to say no to interruption

Dear KV,

I just started my first software development job after graduating and was wondering if software development always involves so much conversation. Our small team of six seems to spend far more time discussing code than actually writing it. Between daily standup meetings (we use scrum in our company) and the need to constantly respond on the company Slack channels, it's hard to get a moment of quiet. Even though I work from home several days a week and live alone, there's rarely a moment peaceful enough to concentrate on writing code, which is my actual job. How do you get the quiet time you need to work on code away from all the noise—virtual or otherwise—that seems to come along with this line of work?

—Seeker of Peace

Dear Seeker,

The short answer would be to delete Slack and everything else used for communication—except perhaps an email client—from all your devices. But, of course, as a new recruit, you rarely have the power to say "No!" to the people with whom you work. And work culture has just gotten louder and more annoying as we've continued to add more distractions that someone—somewhere—seems to believe we need.

KV is old enough to remember a time before ubiquitous cell phones, a world in which email was the predominant form of intra- and interoffice communication, and it was perfectly normal not to read your email for hours in order to concentrate on a task. Of course, back then we also worked in offices where co-workers would readily walk in unannounced to interrupt us. That too, was annoying but could easily be deterred through the clever use of headphones—or, in KV's case, a dead-eye stare.

The communication applications themselves, however, are not at the root of the problem. Before Slack and Discord, there was IRC (Internet Relay Chat), which served the same function, except that you had to use ASCII art to be rude. (And no, I'm not going to explain how; you can look that up on your own.) The problem here, as is so often the case, is people. While there are mechanisms for removing all the people, I understand they are still frowned upon in the workplace.

Scrum and its attendant annoyances arose because people don't trust each other and often do not communicate well. The same might be said for the "everyone on Slack" mentality. Managers and product owners feel they must be kept in the loop on how things are going because that's how they can keep tabs on whether they'll be able to deliver—on time and on budget—whatever it is that you're supposed to be working on.

Of course, having someone watch over you constantly, who has the ability to constantly interrupt to ask, "How's it going?" is like having a six-year-old in the car who repeatedly asks, "Are we there yet?" And yes, the daily standup is very much the work equivalent of "Are we there yet?" It isn't that scrum can't be used well. Like any methodology, it has its uses. Once it starts to be applied with religious fervor, however, it loses its original meaning and becomes nothing more than a Latin litany repeated endlessly by the team to stave off eternal punishment.

Many years ago, KV worked with some researchers who had active badges. These were devices (back before cell phones, if you can imagine) that could be used to send brief messages within a workplace networked for them, as well as to track users within a building. That's so you would know, for example, that Bob happened to be in Alice's office at the moment. We mostly used these things to congregate for lunch. But, as technologists, we also wanted to find out what weird things we could do with these widgets. There were a few papers written about the technology at the time, but the most incisive work on the badges was not about the gadgets or the network protocols themselves but instead about how work cultures might use or abuse the technology (see "Locating systems at work: implications for the development of active badge applications," by R.H.R. Harper, M.G. Lamming, W.M. Newman).

Is it OK to know that Bob happens to be using the toilet just now? What if the system counts how often Carol visits the coffee machine? The most important finding from the study, which will remain important no matter what form this sort of contact technology takes, was that the thing that mattered most was who had the ability to determine the rules. That is, a workplace in which people were required to wear the badge at all times and respond to messages at all hours would be considered a bad place to work, whereas a business where it was considered to be OK to put the badge away somewhere so as to have a bit of uninterrupted time to work or just rest would be considered a good workplace.

This seems simple enough. Yet, as we watch people now dealing both with back-to-the-office policies and this requirement for people to be constantly available for contact, KV is pretty sure no one is paying attention to what was already learned.

As to your original question about whether software development requires conversation, the answer is always yes. That's because, unless you're writing only for yourself, whatever software you build will need to work with what others are building—and, in the absence of communication, the bits won't line up. So, the meta question is: "How much communication is required?"

KV is now of the opinion that we could all do with a lot less interruption and quite a bit less conversation. To solve this problem for yourself requires that you work in a place where saying no to interruptions is acceptable—or even, perish the thought, encouraged!

George V. Neville-Neil works on networking and operating-system code for fun and profit. He also teaches courses on various subjects related to programming. His areas of interest are computer security, operating systems, networking, time protocols, and the care and feeding of large codebases. He is the author of The Kollected Kode Vicious and coauthor with Marshall Kirk McKusick and Robert N. M. Watson of The Design and Implementation of the FreeBSD Operating System. For nearly 20 years, he has been the columnist better known as Kode Vicious. Since 2014 he has been an industrial visitor at the University of Cambridge, where he is involved in several projects relating to computer security. He earned his bachelor's degree in computer science at Northeastern University in Boston, Massachusetts, and is a member of ACM, the Usenix Association, and IEEE. His software not only runs on Earth, but also has been deployed as part of VxWorks in NASA's missions to Mars. He is an avid bicyclist and traveler who currently lives in New York City.

Originally published in Queue vol. 23, no. 3—
Comment on this article in the ACM Digital Library

More related articles:

Titus Winters, Leah Rivers, Salim Virji - Develop, Deploy, Operate
By taking a holistic view of the commercial software-development process, we have identified tensions between various factors and where changes in one phase, or to infrastructure, affect other phases. We have distinguished four distinct forms of impact, warned against measuring against unknown counterfactuals, and suggested a consensus mechanism for estimating DDR (defect detection and resolution) costs. Our approach balances product outcomes and the strategic need for change with both the human and machine costs of producing valuable software.

João Varajão, António Trigo - Assessing IT Project Success: Perception vs. Reality
This study has significant implications for practice, research, and education by providing new insights into IT project success. It expands the body of knowledge on project management by reporting project success (and not exclusively project management success), grounded in several objective criteria such as deliverables usage by the client in the post-project stage, hiring of project-related support/maintenance services by the client, contracting of new projects by the client, and vendor recommendation by the client to potential clients. Researchers can find a set of criteria they can use when studying and reporting the success of IT projects, thus expanding the current perspective on evaluation and contributing to more accurate conclusions.

Abi Noda, Margaret-Anne Storey, Nicole Forsgren, Michaela Greiler - DevEx: What Actually Drives Productivity
Developer experience focuses on the lived experience of developers and the points of friction they encounter in their everyday work. In addition to improving productivity, DevEx drives business performance through increased efficiency, product quality, and employee retention. This paper provides a practical framework for understanding DevEx, and presents a measurement framework that combines feedback from developers with data about the engineering systems they interact with. These two frameworks provide leaders with clear, actionable insights into what to measure and where to focus in order to improve developer productivity.

Jenna Butler, Catherine Yeh - Walk a Mile in Their Shoes
Covid has changed how people work in many ways, but many of the outcomes have been paradoxical in nature. What works for one person may not work for the next (or even the same person the next day), and we have yet to figure out how to predict exactly what will work for everyone. As you saw in the composite personas described here, some people struggle with isolation and loneliness, have a hard time connecting socially with their teams, or find the time pressures of hybrid work with remote teams to be overwhelming. Others relish this newfound way of working, enjoying more time with family, greater flexibility to exercise during the day, a better work/life balance, and a stronger desire to contribute to the world.