...meetings pull you from doing actual work in order to talk about doing work. It’s easier to push a branch up, check out the diff, and then iterate on that diff rather than assuming you’re going to perfectly whiteboard system design ahead of time.
This seems over-broad to me, and seems to violate the accepted wisdom "Good programmers spend 10% of their time coding, and 90% of their time thinking." A good system/design meeting can go a long way to producing better code.
The problem with the whiteboard design is that you have to defer, "oh, let's see if that works" indefinitely. While you spend 90% of your time thinking and 10% typing, you don't spend 9 hours thinking and then 1 hour typing. You spend 5 seconds typing, then 30 seconds thinking, then a minute or so typing, and so on. Getting feedback from the computer is important for anything that's complicated enough to require a design. Seeing what the code looks like that your design enables is as important as a conceptually-sound design.
The main problem is that 99% of programmers don't know how to prototype. They assume that whatever they commit is what goes into production. No. Try an idea quickly and throw it away if it's bad. That's why we have languages like Perl, Python, and Ruby. While it's 50/50 on using them for production, they are absolutely the right tool for testing your ideas quickly.
And if you can test ideas quickly, you don't need meetings. Spend an hour coding what you would have talked about in the meeting. Share with coworkers. Get feedback. Tweak the prototype. Then write the "ready for production" version.
I've been to a lot of meetings but I've never seen any piece of code look anything like what was described in the meetings. As soon as you hit that one point where the computer's view of things and your meeting's view of things diverges, everything else you discussed in the meeting is invalidated. The computer is always right.
(Actually, one of the answers I got to an interview question at Google was so cool that I had to code it. And the code looked exactly like the design I sketched on the whiteboard. And it ran really fast on a large dataset. So maybe meetings are useful; but only for algorithm design, not for "real-world" stuff like "how should we refactor this thing".)
The main problem is that 99% of programmers don't know how to prototype. They assume that whatever they commit is what goes into production. No. Try an idea quickly and throw it away if it's bad. That's why we have languages like Perl, Python, and Ruby. While it's 50/50 on using them for production, they are absolutely the right tool for testing your ideas quickly.
That's one possibility. However, I can't help but find the idea that you have some kind of arcane knowledge that 99% of all programmers don't have is a bit... well, egotistical. Prototyping certainly has its place, but its purpose is completely orthogonal to that of a meeting. Meetings serve to plan. They get everyone on the same page. Prototyping serves to test ideas out.
The problem is that meetings are almost always ruined by a small minority of people who insist on dragging them out. However, a good meeting is very helpful.
My experience is that 99% of the time in meeting is spent on some issue that the computer could tell you very quickly. "This is O(n^2), but it's faster than the O(n log n) algorithm on modern hardware." Rather than debate, benchmark and explain the results to the group. Speculating gets us nowhere.
"What's a long email? 1000 words? 5000 words? 10,000? Let's call it 10,000, just to be over the top. I can scan read at 800 wpm, and finely read at 250 - 500. So absolute worst case scenario I'll have to spend 40 mins reading an extraordinarily long email. That is still better than an hour long meeting where I'll listen at 40 to 80 wpm and have completely no recollection of it two weeks from then. So why the fuck do we consider ten thousand word emails completely insane but we even entertain the idea of an hour long meeting?"
Obviously something like campfire or flow or whatever is better than emails, but I'll take long emails over meetings any day of the week.
You have a point. But you are assuming that meetings are about exchanging textual information. Usually there's more than that.
It's often important to get an idea about how stakeholders feel about different ideas. You can see facial expressions of everyone in a room and hear the way people speak at the same time as you're processing what's being said. All this information will not be in your chat/email thread at all. Also, not everyone is a great writer, many people will communicate much less details in writing than in person. Part of the reason why management likes meetings more than developers is because non-verbal data tends to be more important for their jobs.
Plus, what about visuals? Drawing on a whiteboard is easier than drawing in any software package I know of (even if you've got stuff like Wacom tablets). It's also easier and much faster to point to something than to explain it verbally.
Overall, I think the benefits of asynchronous workflow far outweigh the drawbacks (btw, anyone got a list of companies that use it? :), but it's important to understand the drawbacks as well.
Ideally, the hour-long meeting is a collection of many small communications from several different people. If meetings consist of getting talked at by one person for an hour, I think most would agree that something is wrong.
A good system/design meeting can go a long way to producing better code.
The problem is that these are so rare. The vast majority of meetings in every company I've worked at are of the "invite everyone so it turns into a contest to see who can make their point the loudest" variety, and almost always end up with a few people who view it as their chance to be the "star" to a captive audience and thus draw out the meeting as long as they possibly can.
Plus, if your programmers are any good, they're probably holding these meetings already without management having to formally call a meeting. I think that's the real problem: "formal" meetings almost always suck. Ad hoc meetings held by people who need communication to finish their job usually make up for themselves in increased productivity.
Think about it. Did Linus Torvalds sit down at a big meeting and design Linux on a whiteboard? Did the Mozilla team design Firefox at their daily stand-up meeting? Did Emacs evolve from detailed discussions and specs, or did someone write some macros for their favorite text editor and it evolved over time?
Great software isn't planned. Great software happens. Bitching about minor details in multi-person meetings is just a waste of time.
If you want to waste time, get a beer and read HN for a while.
"A complex system that works is invariably found to have evolved from a simple system that worked. The inverse proposition also appears to be true: A complex system designed from scratch never works and cannot be made to work. You have to start over, beginning with a working simple system."
This seems over-broad to me, and seems to violate the accepted wisdom "Good programmers spend 10% of their time coding, and 90% of their time thinking." A good system/design meeting can go a long way to producing better code.