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...
For further actions, you may consider blocking this person and/or reporting abuse
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. 😄
Even as a Frontend dev & technical writer, I dread long calls. Now you've messed up my research and flow. Then I have to go back again and get into it. It's important when straight to the point and short. But once it's long and repetitive, it becomes a waste of time... I love your article!
Totally feel you - nothing ruins both coding and writing flow like a “quick call” that turns into a time sink. 😅
Short and focused? Great.
Long and repetitive? Goodbye brain.
Thanks for the kind words - wishing you more flow, fewer meetings! 🚀
Couldn’t agree more—meetings without clear outcomes kill focus and momentum. Love how you broke down the real cost of context switching. 👏
Thanks! 🙌 Exactly - the real cost isn’t the 30 minutes on the calendar, it’s the hour of focus you lose after it.
Meetings without outcomes don’t just waste time - they delay the work that was already in progress.
Glad the context-switching point hit - that’s the part non-devs usually underestimate the most. 😅
This is so relatable XDDD
Wow, such a great thought you share here Sylwia!
Thank you! 😊 Glad it resonated!
Great read, as always!
Just one thing. You forgot to translate (or remove) a sentence:
"Super — oto lista badań i statystyk w formacie Markdown, które możesz łatwo wkleić jako „bonus research”."
😉
Haha, thank you so much! And I was so proud of myself for coming up with the idea to add that section! (What’s more, I still had to wrestle with Markdown.)