Was this post written during a long, pointless meeting?
Of course not!
…Or was it? 👀
Let’s start with this: I’ve been in the industry for over ten years. I’ve met all kinds of developers - including the stereotypical introverts who would rather refactor legacy code than talk to another human being.
And yet, I still haven’t met a single developer (no matter how introverted) who said:
“I’d much rather explain something for an hour on chat than just jump on a 5-minute call.”
(For office folks: replace “call” with “walk up to someone’s desk.”)
So no - we don’t hate people or conversations. Quite the opposite!
A short, focused call is gold for any developer. 💎
What we hate is something entirely different.
Endless, soul-crushing meetings 😵💫
You know the kind:
*️⃣ It could’ve been an email.
*️⃣ The same topic gets re-hashed for the tenth time.
*️⃣ Half the attendees have no idea why they’re even there.
*️⃣ Someone inevitably shares their screen and talks for 30 minutes straight.
As a senior dev / tech lead, you can get completely trapped in meetings.
In my previous company, I caught myself avoiding complex tasks — not because they were hard, but because meetings would make them take twice as long as they would for a junior dev with no calls that day.
Meanwhile, some “meeting person” feels accomplished because they scheduled a call “with many important people.” 🎉
And I’m not innocent either. Once I scheduled a 12-person call… only for the other team’s tech lead to say:
“Well, we’ll see. We need to check.”
That was it. That was the whole value of the meeting.
At least I felt ashamed for wasting everyone’s time. 🙃
The Myth of Multitasking 🧠❌
Some people - usually non-technical - believe that lots of meetings are fine because:
“You can just do something else in the background.”
Yeah, no. That myth was scientifically debunked last century.
There is no “multitasking.” There is only context switching - and it drains brainpower like crazy.
So you either:
- Tune out completely and do your own work (in which case… why were you invited?)
- Try to listen, knowing at any moment someone may say: “Let’s hear what you think.”
Result: you can only do simple, low-effort tasks - or, if you have none, you may as well write a blog post. 😉✍️
Software Development ≠ “Just Typing Code” ⌨️🧩
People often don’t understand the nature of software development.
Real development requires deep focus. And when that focus lasts long enough, you enter the famous flow state - where:
✅ things finally make sense
✅ the problem is “loaded into RAM”
✅ progress becomes fast and satisfying
…until a calendar notification pops up:
“Let’s have a 45-minute call to discuss something we already discussed three times, just to document it properly in a spreadsheet.”
or:
“Let’s invite 20 people to brainstorm a feature we might implement in 2028.”
A dev with three 1-hour meetings does not have 5 fully productive hours left.
After a meeting, you’re mentally drained and you need time to reload the entire context of your work.
That’s not laziness. That’s simply how the brain works. 🧠⚙️
🎯 Bonus Research
- Research shows that it takes an average of 23 minutes and 15 seconds for a person to get back to their original task after a context switch. (Monitask)
- According to one source, context-switching can reduce productivity by 20% to 80%, depending on how many switches and their type. (trunk.io)
- It is estimated that context switching costs the global economy approximately US$450 billion annually. (atlassian.com)
- One report found that the time staff spend managing and attending meetings costs employers an annual average of US$29,000 per employee. (WorkLife)
- A study by London School of Economics and Political Science found that ≈ 35% of business meetings are unproductive, with the overall annual cost to firms of unproductive meetings estimated at US$259 billion in the US. (lse.ac.uk)
- Only ≈ 30% of meetings are considered productive, and only ≈ 37% actively use an agenda. (Notta)
So what is a good meeting? ✅
Short. Clear purpose. Right people. Output > conversation.
Below are some practical tips you can steal 👇
🛠️ Action Points: How to Run Developer-Friendly Meetings
✅ Ask yourself first: “Do we really need a meeting? Can this be a comment, ticket update, or 3-message chat thread?”
✅ Invite only the people who actually need to be there. Optional attendees = async notes.
✅ Define the goal in one sentence. If you can’t — you’re not ready to schedule a meeting.
✅ Set a default length of 15 min. Extend only if needed.
✅ Start with facts, not storytelling. “Here’s the problem. Here are the options.”
✅ End with a decision and owner. If no decision was made — the meeting failed.
✅ Send a 3-bullet summary after. So no one has to join “just in case.”
Bonus tip:
If you must brainstorm, use async pre-work so the call starts at solution level, not catch-up level.
💬 How much flow time did you lose this week because of meetings? Drop a comment — let’s calculate the real cost of calls.
Top comments (40)
Great read, you nailed what happens when process turns into performance.
Meetings often start with good intent (sharing context) but they end up replacing the context itself. Real collaboration begins when we stop proving we’re working and start thinking again.
As for your question: I don’t waste time in meetings anymore. I just don’t have time to play. 😉
Haha, that tracks perfectly with your “one-person company / zero-agile” philosophy 😄
When you are the whole team, the sprint review, and the retro - meetings really are just… cosplay.
And honestly, there’s something refreshing about that clarity:
no rituals, no dashboards, no “alignment sessions” - just do the work, ship the work, move on.
Meanwhile the rest of us are still trying to figure out how to politely say
“This meeting could’ve been a repository README.”
Exactly 😄
I guess I just turned “asynchronous collaboration” into “internal monologue with coffee.” ☕
But yes — the clarity is real. No dashboards, no check-ins, no pretending to align — just doing the work.
And you’re right: half of those meetings could’ve been a README, and the other half should’ve been deleted.
“Internal monologue with coffee” is honestly the most accurate definition of async work I’ve ever seen 😄
And yes - the moment you remove the performance layer, the work suddenly gets weirdly simple.
Maybe the real senior skill is just:
Write it down, ship it, and don’t schedule a meeting about it. 🚀
You know, that line could easily open Agile Theater IV.
(III’s already set for next week.) It fits the core idea perfectly — work gets clear once we stop performing it.
We might have just drafted the opening lines together.
@pascal_cescato_692b7a8a20
Haha, deal - I’ll take co-writing credit on Agile Theater IV then 😄
And yes, that’s the whole plot twist: once you stop performing “work”, the actual work becomes obvious.
Ensure the meeting description has expected outcomes and end the meeting once achieved.
You're right… It's an highly effective and unstoppable method.
And don't accept meeting invites without expected outcomes 😂
💯 That’s the real meeting hack:
✅ clear outcome
✅ stop when it’s reached
✅ decline everything that doesn’t have one 😄
Imagine if every calendar invite had to pass a “why does this exist?” test…
Half of corporate life would just evaporate 😂
As soon as you have a certain level of seniority, it is your duty to push the organization to a better meeting culture.
Don't passively decline meetings that dont't meet certain criteria.
Go to that meeting and ask questions: "What is the goal of this meeting?"
If you are passionate - say it at the end of a meeting: "This is a waste of my time - this could have been a README file."
You can even point out what a waste of money a meeting is:
people * hours * avg. salary = wasted moneyJust the other day I discussed with two collegues, for an hour, how we might test a bug on a certain hardware. At the end we concluded that we need the hardware. This was our initial demand. Now we wasted more money discussing it, than the costs of aquiring the hardware.
Don't be too radical. Sometimes we need brainstorming meetings. This is fine. Make sure to participate - you have been asked to be there, because your experience/opinion is valued.
Pro tip for the not-absolutely-introvert: You should not only attend to meetings, you should participate. You can add value to a meeting.
Love this take - especially the part about being active instead of just silently declining invites.
You're right: past a certain level, “complaining about meetings” stops being edgy and starts being laziness.
If we want fewer useless calls, someone has to say out loud why they’re useless.
Also agreed: not all meetings are evil - the problem isn’t talking, it’s talking without purpose.
A good brainstorm with the right people can save hours of solo struggle.
A bad meeting can burn hours of salary faster than any cloud bill. 😅
Thanks for adding the “ownership mindset” angle - it’s a level above just ranting, and I respect that. 🙌
Great article; completely nails the problem with meetings in tech. I’ve lost so much flow time to unnecessary calls. The key takeaway for me: if a meeting doesn’t have a clear outcome, it shouldn’t exist. Thanks for the reminder to keep things concise and purposeful!
Thanks! 🙌 And yes - flow time is the real currency in dev work, not hours on the clock.
Totally agree: if a meeting has no clear outcome, it’s not a meeting - it’s a calendar-shaped distraction. 😅
Here’s to more async clarity and fewer “just-in-case” calls!
This is so true! 👏 As someone who’s worked with both dev and marketing teams, I’ve seen how meetings can completely break focus and momentum. The “context switching” point hit hard — it’s not about hating collaboration, it’s about protecting deep work. Loved the practical checklist at the end — short, clear, and actually usable. Every manager should read this one before scheduling their next “quick sync.” 😅
Thanks so much! 🙌 And yes — once you’ve seen both sides (dev and marketing), you really notice how differently each team experiences meetings.
Dev work isn’t allergic to collaboration — it’s allergic to interruptions disguised as collaboration. 😅
Glad the checklist landed!
If even one manager cancels a “quick sync” after reading it, we’ve already made the world 0.01% better. 🚀
Couldn’t agree more! meetings themselves aren’t the problem, badly run ones are. Developers thrive on focus and deep work, and every unnecessary sync chips away at that. Love your emphasis on having a clear goal, short duration, and defined output. That should be printed on every meeting invite.
Thank you! 🙌 Exactly - meetings can be great when they have purpose and direction.
It’s just that so many turn into “talking about talking” instead of actually deciding or doing. 😅
Totally agree - every invite should come with a reminder: goal, duration, outcome - or don’t send it! 🚀
Could not agree more. As much as I like to work from home, the fact that more and more people started working remote in the last years have only attributed to the 'Death by meetings' issue.
And lets not forget the root of all evil: Teams chat.
Exactly - remote work saved us from commuting, but invented a new sport:
“How many meetings can we stack before anyone notices no work is happening?” 😅
And Teams chat… the only place where messages are both instantly urgent and already buried forever at the same time.
We’re not blocked by code anymore - we’re blocked by calendars.
If the meeting doesn’t produce a decision, artifact, or meme → CANCEL IT.
Absolutely. A meeting should end in output, not vibes.
If we walk out with no decision, no document, no next step - at least give us a meme so the pain wasn’t wasted. 😄
I just want to add this article to the discussion: it covers most points in this article and adds even more perspectives: terriblesoftware.org/2025/06/24/wh...
Thanks for sharing - great article, and it really covers the topic from a much wider angle than mine.
My post zoomed in on just one slice of the problem (meetings vs. developer flow), but the whole manager–developer dynamic is a much bigger conversation - you could easily spend hours unpacking all the layers there. 😅
Appreciate the addition to the discussion!
Communication. All depends to communicate well. After all, coding is a tool of our products. If we do these jobs to get money, we should not set our mind tools as mainly objects.
Software development is a tool to develop digital twins of real world. Our main problem is to develop a qualified product to get money, or something you want. For this, "communication" is the most powerfull factor. In a cluster, any type of cluster, the persons who communicate bad cannot develop qualified products.
Absolutely - good communication is the foundation for everything we build.
Even the best tools or code don’t matter if people can’t share ideas clearly or align on goals.
At the end of the day, great software really is a side effect of great collaboration. 💬✨
Honestly, it’s not about the time — it’s about context switching. When you’re deep in solving a problem or writing code, even a 15-minute meeting can break that mental flow. It takes another 20-30 minutes to get back into the zone. Developers don’t hate collaboration; we just prefer async communication that respects focus time.
Exactly - that’s precisely what the article was about! 🙌
It’s never about avoiding people or collaboration - it’s about protecting that fragile “flow” state that makes deep work possible.
Async isn’t antisocial - it’s just respectful of how focus actually works. 😄
Some comments may only be visible to logged-in visitors. Sign in to view all comments.