How did you get work done in meetings? By definition, meetings are stopping work to communicate; the most work-efficient approach is to optimize away the need for meetings as much as possible.
You have implicitly and uselessly defined "work" as "everything you do that's not communicating".
I can write code and solve problems all day long by myself. So can my coworkers and housemates. When we have meetings at work, we figure out which problems to solve and why. Why is it that the coding part is considered "work" and the meetings is considered "not-work"? I would just be a lone programmer working on subsets of the wrong problem without the meetings. Lately, I feel like the "work" gets done in the meetings, and I just tidy up afterwards (for a few days) by myself. That's because the answers are easy, but the right questions are hard.
Let's try this: meetings are stopping implementing to communicate. Or, from another perspective, coding is postponing meetings until new issues/questions have been solved.
In kernel terms, meetings and PMs are the scheduler, and you are the threads/processes being scheduled.
Is the scheduler doing work? Yes. Is that work simply overhead required to keep the pipeline full and fair scheduling of work occuring? Yes.
> Let's try this: meetings are stopping implementing to communicate or from another perspective coding is postponing meetings until new issues/questions have been solved
Or to put this another way, meetings are a page fault interrupt that is taken because the necessary backing store (the solution to issues/questions) is not available.
They're almost pure cost. Spending any more time there than you absolutely need to is a waste.
This is a tautology. Spending any more time anywhere on anything is a waste. The point that you're missing is that just because some meetings add no value doesn't mean that no meetings add value.
The fact that some meetings add value doesn't mean all or even most meetings add value.
My analogy holds; page fault handlers add value. They also incur a heavy cost and you want to avoid faulting if it at all possible.
I'm sorry you've had such a bad experience with meetings; it must be common or the stereotype wouldn't exist. My workplace is different. Since my most valuable work is accomplished in meetings, I wish I could be in meetings all of the time. The only reason I can't is because we frequently need long breaks to implement the work we did in the meetings. In fact, coding is a much heavier cost than meetings; unnecessary coding is much worse than unnecessary meetings and you want to avoid unnecessary coding at all costs (even though it's usually still quite fun). Just because you develop software doesn't mean you should spend as much time as possible writing code. Just because you produce code at work doesn't mean you're only working when you're coding.
This is where we disagree. Talking about work isn't tangible work. Talking unblocks work, to a point.
> I'm sorry you've had such a bad experience with meetings; it must be common or the stereotype wouldn't exist.
Given that my experience spans roughly 15 years, major corporations, small and large startups, in both management (director, VP, and C-level roles) and engineering (software, systems) I'm inclined to trust my experience that meetings are generally a work-substitution mechanism and a means of furthering political/social career advancement, and bad PMs (which is, sadly, most of them) are the worst offenders of them all.