To whom? For my sanity and productivity that's the most important at least.
I only enjoy working when I am in that flow state captured by the problem without having to worry about interruptions.
This is when I provide most actual value and also get most enjoyment out of work myself.
Everything that takes me out of it feels like annoying and frustrating interruptions.
And usually I have to then try to not show my frustration and act like I am happy to do small talk or whatever, so I wouldn't seem rude.
"To whom? For my sanity and productivity that's the most important at least."
Optimizing for you vs the team is often not the goal.
"This is when I provide most actual value and also get most enjoyment out of work myself."
In most companies, it's much more valuable to have a team productive than a single individual, even if it comes at a cost to the individuals.
IE Assume a team of 10, and that working like you suggest provides 1.5x productivity for you, but you working like this cost 0.15x to each other person on the team because you are slower at responding, etc.
If it had no effect on anyone else that would be super weird (it would mean nobody depended on anyone, etc. Basically that being a team didn't matter).
Let's assume when you don't work like this, it cost nobody else anything, but is really crappy for you (0.6x)
With you working like this, team productivity is 1.5x+(9*0.85x)= 9.15x.
Without you working like this, team productivity is 0.6x + 9x = 9.6x.
Obviously it's different at different numbers and tradeoffs, but optimizing for individual productivity, when it costs things for teams, can often end up a net loss. Not always of course.
You can argue it costs nobody else anything but i think that would honestly be a silly argument. We should admit there are positives and negatives to the tradeoffs here, and sometimes the aggregate works out and sometimes it doesn't.
For a developer, arguably "flow state" is arguably the most important thing. Provided, that is, that requirements are clear and people are in sync what should be worked on.
What do you think is the most important, if not flow state?
Well, you kind of assumed it away in your second sentence, but alignment is more important than individual productivity. And unfortunately, meetings, interruptions, and other communication are the best tools most teams have for that.
> And unfortunately, meetings, interruptions, and other communication are the best tools most teams have for that.
In my experience, once people know each other well (whether via direct face to face communication, or via observing each other's slack messages and PRs), it's much more efficient to put things in writing.
Then everything is in the open, for everyone to see and discuss/comment on. People can go back over previous decisions, people can see the context over why something was done, people can check previous votes. And, most importantly, people can do so when they need to do so, preserving their individual flow state.
By the way, when I said "flow state", I also mean the team's overall flow state, not only ICs.
E.g if we break down a feature in two parts, can we efficiently sync so the parts we make fit well together. Do we pair program, do we each take our chunks, how often do we sync and how, that's also "flow". My point is that "flow" here is still the most important thing for developer productivity. If you want to be doing your own part of the task, but I keep interrupting you with "hey, got 5 min", obviously something is wrong in our flow.
What is more, I can't be convinced that allowing these interruptions is the proper way, the price of achieving flow. I see that more as a symptom that we didn't agree on the ground rules, and that's where our flow goes wrong. Maybe we can batch the multiple 5 min interruptions into longer planned sessions, with agendas, where we go over your concerns and questions, which you spend the time to formulate and put on paper. That way we have a focused time with an agenda and we both can prepare for it, and there are no context switches for the rest of the workday.
I think the problem is that you consider "alignment" a thing on its own, but to me it's merely one of the components needed to achieve a good flow. In experienced teams where members are attuned to each other's communication styles, and respectful of each other's time and attention span, alignment doesn't necessarily need to be attained by meetings and interruptions.
Hence my point still stands that flow (individual and team) is the most important thing for developer productivity (and happiness)
Teams are not a simple sum of independent productivity of individuals.
(If they are, it implies they don't need to be a team, since nobody is dependent on anyone else)
You say that like it's not possible to have a balance—have enough meetings and communication to properly coordinate the team, while still leaving each individual enough uninterrupted time to get plenty of flow-state work done.
The posters above advocating for flow state aren't saying anywhere that they don't want to have any communication with the team. They're saying they need the flow state to get their own work done. That's fully compatible with agreeing, as a team, that there are certain times when you don't interrupt your teammates short of an emergency—and other times when everyone's fair game, and still other times for regular scheduled meetings.
So many of the "quick calls" could just as easily wait until tomorrow, or a scheduled block of "interruptible time" at the end of the day. Saying "But I need to interrupt you now!" during a time designated for deep work means that you're optimizing for your individual productivity rather than the team's; instead, you could write your question down for later, and switch to a different task for the time being, or work around it, or research it yourself, or a dozen other possibilities.
While that is true, good team members don't interrupt each other and make sure they maximize both their individual and team interactions.
"Hey, you got 5 min" all the time is a symptom of bad communication and bad team flow. It means lots of things are not clear, often, things that can be put in a knowledge base, or batched into a longer conversation.
The price we pay as an organization when team members switch context is high, and if your culture is a culture of constant context switch, then it's not a good culture. Let's not normalize interruptions as "the price to pay" for being in a team. We can be in a team with better dynamics than that.
