Flow state is really powerful, but it’s not constant. I don’t want to be in flow for 40 hours per week. And to tell the truth if I get a few hours of flow a week, I’m lucky.

So I don’t want to shut the door on any interactions in the unlikely chance that it interrupts me in my optimal state.

What I like to do is block off “deep work” in my calendar a few times a week. Then people can think about if they want to interrupt.

This has let me look at these “quick call” or “hi” messages as just part of being human and having a pleasant team where people are happy to interact rather than dings to maximum team productivity.

Unfortunately as of lately my professional life has been terrible for flow state due to various reasons related to working in a corporation. So I might consider switching jobs. Interruptions, blockers, depending on others, etc.

But I love being in flow state, luckily I can still do it with my side projects. With side projects without being interrupted I can easily spend the whole day coding and at the same time building 10x to 100x as much as at a corporation job. Of course it's less realistic in a large company to have it, but I just wish my actual work was like that.

Maybe if I could make one of my side projects to bring in enough, I could just do that. I would say that would be a dream.

> This has let me look at these “quick call” or “hi” messages as just part of being human and having a pleasant team where people are happy to interact rather than dings to maximum team productivity.

It just depends on the human type I guess. Extraversion vs introversion.

> But I love being in flow state, luckily I can still do it with my side projects. With side projects without being interrupted I can easily spend the whole day coding and at the same time building 10x to 100x as much as at a corporation job. Of course it's less realistic in a large company to have it, but I just wish my actual work was like that.

Unpopular opinion: a very small team of skilled programmers that have experience working together and are often/continuously in flow (whether alone, or pair programming), can 10x/100x outpeform multiple teams in a large corporate setting.

I definitely agree with that, and I have been on both sides of the coin, with a little team doing a lot of projects very quickly and also a corporation job where things move very slowly. Also having done so many side projects.

The unfortunate usual thing is though that the jobs that pay a lot usually involve a lot of people. Because when a small group of very productive programmers start out, their business is not proven yet, but when it actually is proven and will start to make a lot of money, there will be a lot of people hired and which breaks what it had initially.

And the more people and teams you put on something the slower the pace will be per developer, for sure.

There are moments in time in a lifecycle for a start up or a business, where there is that golden point, but it always seems temporary.

> Because when a small group of very productive programmers start out, their business is not proven yet, but when it actually is proven and will start to make a lot of money

What if we stop at making a lot of money in a proven business, and don't hire more unless absolutely necessary? Keep the team small and lean, retain the talented people who brought you here via profit sharing, and just...relax?

I am surprised that this model is almost non-existent.

It is an unstable model; if it’s only necessary to hire when someone leaves, there’s no slack - what if someone gets long term sick? What if someone feels burnt out holding the thing up but nobody else wants to hire more - by the time that person leaves it’s necessary to hire more but also late to start the hiring process to find the perfect one replacement and who has spare time and redundant knowledge to train them?

When it will start to make a lot of money, it will do that by having lots of customers, therefore more support requests, more payment troubles, more feature requests, more scaling concerns, reliability and maintenance.

When it starts making money, competitors will notice and may start copying it; relaxing will let them catch up and pass you and take your customers.

There is always entropy, things fade, decay, things need continual “growth” just to stay in a steady state - getting that growth perfectly tuned so it doesn’t grow bigger and need more employees, and doesn’t shrink and wreck the company, it precisely counters the decay, is much harder than growing bigger.

Lifestyle business is not unheard of, some people hit on a great idea and execution and it’s a money printer for them, but it seems that more people who try it either can’t get enough money, or struggle to do everything without hiring anyone until they burn out, or have to hire someone and then have to get more income to pay them and are in growth mode, not steady state.

Because few are able and willing to NOT take outside money (get investors). Investors want to invest in a cancer not somebody's life-style business.

This is much better and normal rather than the bs the original author is proposing where they are the main character and everyone caters to them

Maybe "flow state" is not the most important thing?

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)

Team and organizational productivity.

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.