Jul 312024
 

When you’re trying to concentrate, 1 of the worse things that can happen is to get interrupted with what’s essentially either a) a status update or b) a request for a status update. It was 1 thing pre-2020 when working remotely was largely a thing people did as-needed, but by this point, even if you’re working in an office* (*for most developers, an big open room, but you get the idea) again, you’d think we’d have used the time where everyone was remote to learn and adopt better ways of communicating updates without having to rely on doing interrupting people.

What do I mean when I talk about interrupting people with things that are effectively status updates? I’m talking about transmitting information in a manner that triggers a push notification on the receiving end just to communicate information that requires no action on the receiver’s part. Either it’s making a phone ding, prompting people to divert their attention from what they’re working on to look at something else (the same thing that probably has the greatest number and/or quality of distractions no less!), or it’s a pop-up on a computer showing up in the corner of your eye and breaking into the things you’re trying to focus on.

Sometimes, that interruption is necessary. There could be a production incident, an important or pressing customer question that needs answering quickly, or it could be a new high-priority item that needs you drop what you’re working on to address. Those are valid reasons to say, “Hey, stop whatever you’re doing, because this is more important.” The problem is, everything is communicated this way. To paraphrase Syndrome (the villain from The Incredibles), “If (everything’s worth interrupting what people are working on), then (nothing) is.” In reality, updates that trigger push notifications should be like monitoring alerts – limited just to the stuff that’s truly important, otherwise everyone learns to ignore them (if they don’t set up spam filters to keep them out of their inbox altogether).

What’s frustrating is that this is still a thing in a world where we have sites like Facebook and Twitter (it’s still not “X”), and RSS aggregators, where someone can log in and get a list of the most recent things that happened. Heck, almost any project management/work tracking tool has a Kanban interface where, in theory, you could look and see the current status of tickets when you’re interested. So why are we still interrupting everyone for everything?

For all the attempts I’ve seen with companies trying to incorporate a “{insert company name here} social network,” I don’t recall anything just creating a feed from stuff people are already doing so they can go to 1 site and see the list of builds that finished, deployments that just ran, and any changes/updates to tickets. It does the same thing as posting messages to chat or emailing notifications, but it doesn’t try to interrupt what people are working on right now. Instead, they can just get the latest changes when they’re interested and in a position to actually do anything with those updates.

Now, in defense of the “interrupt everyone about status updates” brigade, I’ve met very few developers (and I’m not 1 of them either) who are particularly good at radiating enough information to make this completely unnecessary. That doesn’t mean getting better can’t be something we work on, nor does it mean that the mechanism in which we radiate information means disturbing everyone else. Just because we’re pushing information out doesn’t mean that information needs to intrude on someone who’s in the zone and focusing on things that business presumably needs done.

So what does it look like when the updates we want are more pull-based (the person who wants updates opens/refreshes a webpage and gets them) vs. push-based (information is sent to everyone, regardless of whether they wanted it at that moment or not)? The obvious example (given that I referenced “The Radiating Programmer” earlier), is Basecamp from 37signals. That pull-based philosophy is present throughout their company, and thus their flagship product. Another good example is forum software company Discourse, which has 2 articles about using their product to manage work and how they use Discourse within their company.

The common theme with both those companies is that they’re remote companies (intentionally, not “went remote because of 2020”), which means they built how they work around asynchronous communication. Even if these companies did have offices people worked in, they’d probably still have an easier time getting into flow state and being productive than other teams, because their workflows are built around fewer interruptions and more just getting things done. It’s not like any of this is a secret, although these may have been things a lot of businesses ignored because they were in-office company (“for the culture“). I know that “collaboration” is supposed to be a big selling point of everyone going back to the office, but if that collaboration interrupts people who are trying to work, it’s counter-productive.

It’s entirely possible to keep people in a company up-to-speed on everything that’s going on, at all kinds of levels of detail, without bombarding them with spam notifications. The types of people you think you’re helping with these notifications need to be able to focus, and the ones that are productive in spite of these constant interruptions are going to wind up being the people who found a way to ignore them. Instead, a better way is to find a way to collect these updates somewhere that doesn’t trigger notifications, but is there whenever people who want this information actually need it. It’s worth noting however, that being able to get rid of interrupt-based notifications relies entirely on the rest of us making sure we’re putting the information out there already (preferably in ways that aren’t guaranteed to just ping everyone). Otherwise, nothing’s ever going to get better.

 Posted by at 11:45 AM