Distracting Software Developers Is Far More Harmful Than Most Managers Think

After COVID-19, our work culture has mostly changed for the better, but there were also negative changes — for example, the number of meetings increased by 13.5%.

The problem is that there's a huge gap between how meetings are perceived by managers and developers.

In his famous essay "Maker's Schedule, Manager's Schedule," Paul Graham wrote:

"When you're working on the maker's schedule, meetings are a disaster. A single meeting can blow a whole day."

This problem hasn't been solved with the advent of AI coding assistants; on the contrary, it's gotten worse because managers now think developers can be productive in shorter time intervals.

Over the past two years, we've studied hundreds of developer teams to understand what distinguishes the best ones.

What Is Deep Work?

This term was coined by Cal Newport in his book "Deep Work: Rules for Focused Success in a Distracted World."

Deep Work is work that requires a large share of mental effort, usually carrying some unique value. It cannot be done while you're being distracted! If you can work on a task during a Zoom call, then it's NOT deep work.

Shallow Work is the opposite: tasks that can be done without engaging 100% of your brain. For example, answering Slack/email messages, reviewing a document, and so on.

Software development was once a haven for people who enjoy deep work. The stereotype of a software developer as a loner working in a basement with headphones on didn't appear out of nowhere.

Today, carving out time for deep work is becoming harder and harder, but I believe that when using AI assistants, it's even more important.

Why Deep Work Is So Critical

Deep work is the only way to achieve a state of "flow."

Extended deep work allows developers to:

• Make fewer mistakes
• Maintain work-life balance — they manage to accomplish more in less time, leaving more free time
• Develop their skills — during these periods of concentration, the most difficult tasks are solved and the greatest skill growth occurs

Managers make a big mistake assuming that AI tools make this no longer important. They think developers need to get used to constant context switching — there are only a couple of minutes between prompts anyway, so who cares about distractions?

Because of this, the quality of reasoning and prompts decreases. We get stuck in endless loops: asking AI to fix problems while providing it with low-quality context.

If you stay in a flow state, the deeper you dive into a task, the fewer iterations you need to achieve the same result.

What's the Problem with Deep Work?

Remote work was supposed to solve the problem — no commute, fewer distractions. But in reality, only the first point turned out to be true.

Since 2020, in addition to the overall 13.5% increase in total meetings, the number of remote meetings has also grown by 60%. Unsurprisingly, 92% of employees report trying to multitask during these meetings, and I think for software developers this figure is nearly 100%.

Two main problems arise here:

1. Deep Work Turns into Shallow Work

Remember the simple test we discussed above? If a task can be done in parallel with a call, it's shallow work.

A great example is pull request reviews. If today is a busy day with lots of meetings, when is the best time to review them?

Of course, during a meeting... But pull request review should be deep work! The same applies to debugging and writing design documents.

Doing these tasks during meetings starts a vicious cycle:

• Work quality drops, so more problems arise — more meetings are scheduled to address them
• People are distracted during meetings, so quality decisions aren't made — even more meetings are scheduled...

And this isn't the fault of developers trying to multitask — it's your meeting culture.

2. Developers Don't Reach Flow State

It takes 15 minutes just to get into the groove, and only after 45 minutes does a developer reach peak performance, fully immersed in the task.

Every time they're interrupted, context switching resets this timer. A study conducted by Meta demonstrated the severity of the problem — developers manage to carve out only two one-hour sessions per week!

It's not just the time spent in meetings that's lost. Each interruption sets a developer back 15-45 minutes, which means that even in the BEST case, they manage to accumulate only one to two hours of productive work per day.

I like this analogy I borrowed from a Reddit comment:

"Imagine developers are like miners. Their job is to dig. Every time a meeting is scheduled, they need to pack up all their tools."

Software developers need at least 4-5 hours of uninterrupted work per day, and it's the manager's job to ensure they get this time.

How to Create Time for Deep Work

Improve the Company's Meeting Culture

Fixing it isn't that hard — you "just" need to make sure all managers follow simple rules:

1. Meetings must be effective. A meeting needs a clear agenda and clear outcomes.
2. Set fixed meeting times and leave large blocks of meeting-free time. These can be no-meeting days or hours.
3. Invite only those who are truly necessary; this rule is particularly poorly observed with remote work — today it's become too easy to invite everyone.

What's the best solution? Eliminate as many meetings as possible!

For two years we studied the work of hundreds of developer teams. We were particularly impressed by a team at the company Pylon.

We asked a senior developer to show us their weekly calendar. It was completely empty: no standups, no sprint planning, no recurring meetings.

The company still collaborates, but it happens only when necessary, not at scheduled meetings. This is probably possible because developers are in the office five days a week, but eliminating some meetings is definitely achievable even with remote work.

And if you can't avoid all meetings, we at minimum recommend establishing company-wide focus time blocks. After analyzing data from more than 600,000 pull requests, we found that most developers are most productive during the 09:00-11:00 and 14:00-16:00 intervals.

Reconsider Your Pull Request Process

Do you really need all those pull requests?

The Pylon team also surprised us by having almost no code reviews. Developers merge their own code and request reviews only when they need feedback — for example, when they feel they're making a risky change, or when they're new and still getting oriented in the company.

Code review is a strong distraction for both sides. When you need to review a pull request, you try to do it as quickly as possible so you don't block others, and when a response comes in, you want to look at it immediately. In both cases, flow state is disrupted.

This seems to contradict common sense regarding code quality, but Pylon reasons as follows: if we hired experienced developers and trust them, there's no reason to create a bottleneck with mandatory review requirements for every change.

Lead by Example

After dealing with meetings, you can start addressing other distractions.

The best way to create a good culture is to start valuing your own deep work time and make sure the rest of the team respects it. I must admit that I still struggle with this — I schedule focus time in my calendar and put on headphones, but when I take a break, I sometimes check Slack and reply to messages.

I know this sets a bad example for my team — deep work time should be sacred, and people should know it's perfectly acceptable to be absent from Slack for a couple of hours.

Focus Time Is Becoming Critically Important Today

I believe that the more we rely on AI, the more important focus time becomes. Models will gradually become much faster, and I think companies and developers who learn to enter a flow state with AI will pull far ahead of others.