Toward solving interruption in Programming

Recently there are developers and creative vocal about how interruption ruin their work.

There are many articles about flow state and funny cartoon on how interruption ruin serious thinking work. There is even a passive-aggressive piece talking about teaching non-geeks cost of interruption.

As a developer, while I agree that interruption can ruin work to some degree (which differ for each people), I don't think the passive-aggressive stance most programmer take is productive nor helpful.

First of all, according to my experience in many companies both as a full-time developer, management and consultant, I want to say this out loud:

There is no conspiracy where every non-geek role held a secret meeting to figure out how to make programmer life most miserable and decide that throwing non-sense interruptions every hour is the best course of action.

No, that is not the case.

Every interruption has its own reason. Your teammate has some problem they want to solve, and they think you can help.

That's why they come to you. So tell people to stop interrupting will not work, especially if the problem is a shared problem. For example, what happens if sales are about to commit to some scope but don't know the feasibility? Would you want sales to stop interrupting the programmer and figure this out on their own? That obviously will make the matter worse.

There are some necessary interruptions and some not. You cannot just tell people to leave you alone to solve the problem. After all, you don't get paid to solve your personal problem. It is always a shared problem. Everyone in the team is at stake. Cutting interruptions and work in a silo is not a solution.

I believe the solution is to let them know how to interact with you. You have to set your own boundary.

For example, you can say if anything urgent, please call me instead of a message. You can say that if you leave a message, I will read it within a day. If you ping me directly, I will respond every hour. You can also block your flow time on the calendar.

Those are all valid boundaries to set.

And at first, people might mistake the urgency of the situation. Some people might call you on the tiny issue they have. That is fine if it happened the first time. You take that opportunity and categorize this issue. You tell them that next time this type of issue is not as urgent as they might think. If it happens repeatedly, we have to talk with a team about urgency and tradeoffs since interruption has some cost.

In short, rather than complaining about how others are wrong, it's better to tell what's right. We should let others know how to interact with us productively.

And there might be some constraints that we don't know. For example, we might legally bind to report production issues within a specific amount of time. We can work together to solve that constraint.

But first, you need to believe that people are not out there to get you. As I said, there is no conspiracy of non-geeks. Everyone, geeks or non-geeks, just wants to get the best results. We might have a different opinion on how to get it. That's true. They have a reason, strong or weak, they have a reason.

And shutting others of is not going to solve anything. It is a bad stance to take on the interruption problem. It is much better to take a stance of

And that is my rant for today.