[endiangroup]

AD: I have to disagree with the assumption there are only 3 communication forms (work, async, sync) - it's not hard to fathom a counter example such as Pairing where-in synchronous communication is necessary for the pair's flow state to emerge but they are "working as communication". Likewise there is an assumption here that meetings don't create flow states or that they don't contribute to "work as communication". Not all engineering is writing code and there should be some amount of back-pressure for writing the right code not just writing any code.

However I do agree with a general mentality of do > say which I believe this article is trying to allude to.

[DevOpsy]

I definitely didn't mean to imply in the article that meetings or sync communication in general does not help contribute to flow state. My point of view is that these sessions you do synchronously are also a big part of what makes flow possible, because after them doing the work becomes easier, more clear and flow is more possible. But they are very much necessary to plan, strategize and discuss as you well put it. Also to ensure the right code is written. Although on that note I also feel that all meetings and discussions should have a codified result, especially when it comes to align with engineering principles, coding style guides, and things like that align people in the way they work.

I will need to revise the article to ensure I am clear about that point, thanks for the feedback!