> By definition, meetings are stopping work to communicate

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.

> Why is it that the coding part is considered "work" and the meetings is considered "not-work"?

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.

> 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 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 agree. You asked "How do you get work done in meetings" and implied it was impossible. I argue that just because there is no work accomplished in your meetings or most meetings doesn't mean that no work can be done in meetings. No one anywhere is suggesting that valuable work is accomplished in all meetings. But when you suggest that no work is accomplished in any meeting, you're wrong.

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.

> But when you suggest that no work is accomplished in any meeting, you're wrong.

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.

Man, no offense, but you seem extremely short-sighted here. So when you and a couple coworkers are architecting a system, deciding what the pipeline of information flow is going to be, where the security holes may be, stopping any latency or unnecessary operations, and making sure the user knows how to use the damn thing on top of that - and you aren't writing code, but instead communicating with your coworkers - you don't think that's work? How could it not be?

What is work? Is it the typing of the code, the architecture of the software, or the decisions about what the software should do for the user? The latter 2 can be at least improved in meetings, where the clash of different opinions can produce a better outcome than just one person implementing their whims.