> But knowing your pre-conditions an post-conditions for your isolated parts of your code is important.
Design-by-Contract[0] is a formalization of this concept and well worth considering when working in code using mutable types. In addition to pre/post conditions, DbC also reifies class invariants (which transcend method definitions).
> Even more fun is pointers, especially when windows / macos were switching from 32-bits to 64-bits (in different ways).
And yet even more of a fun time with porting pointer code was going from the various x86 memory models[0] to 32-bit. Depending on the program, the pain was either near, far, or huge... :-D
> This is a phenomena I have yet to experience in the wild.
I have totally seen infinite meetings where nothing is achieved, nothing is really said, but someone socially isolate just talks and talks and talks because it is his only chance to interact.
> I have totally seen infinite meetings where nothing is achieved, nothing is really said, but someone socially isolate just talks and talks and talks because it is his only chance to interact.
Is that communicating though?
Or are those meetings examples of people occupying the same space while audibly moving air with their lungs in order to feel better about themselves?
Maybe this is just my interpretation but OP effectively argued "too many ineffective meetings, we should have less unnecessary meetings and a clearer, independent direction".
The commenter above argued that the problem was slightly different, it's not too many meetings for communication but too many that are not achieving effective communication. A meeting in itself does not create communication (of information and exchange of opinions etc.) and the commenter wanted to increase the number of meaningful meetings instead of/in addition to just cutting down meetings by numbers. The criticism of not enough time spent on communication is in the same vein, both agree on the issue of "too many unnecessary meetings".
Y'all are saying the same thing over and over with slightly different words proposing that the different way of saying it has a meaningful impact on the message. It doesn't.
>"too many ineffective meetings, we should have less unnecessary meetings and a clearer, independent direction".
>it's not too many meetings for communication but too many that are not achieving effective communication
^^ there's no meaningful distinction between those two, discussions that devolve into such things suck all potential value out of a thread.
The distinction is explicit in the statements you quoted. One is advocating for lessening the number of meetings. One is saying that won't help, and instead advocating for increasing the quality of meetings.
* Acknowledging that too many meetings are ineffective
* Suggesting reducing the number of inneffective meetings
* Saying there needs to be clearer, independent direction
The second is:
* Stating that there are not too many meetings in general (the first says nothing about this)
* Acknowledging that too many meetings are ineffective (same as bullet 1 of the first sentence)
* Not suggesting how to address either problem
I agree with GP. There is no meaningful distinction between the 2, but the first suggests 2 ways to solve the problem of ineffective meetings whereas the second simply acknowledges the existing of problems.
> Too much time is spent attempting to communicate and as such, communication isn't actually happening.
This is where I think we have a different definition of communication.
> (i.e. we all spend way too much time in useless meetings where nothing happens and few people are any more informed than they were before)
Hence my clarification of:
Most meetings are not about communication. They are usually
prescriptive in form and dictatorial in nature.
For example, if a project kick-off meeting consists of the highest ranking managers talking and everyone else having no contribution, listen to what they are saying; their "vision" is all that matters.
Another example is when product and/or engineer managers use "stand-ups" to ask each engineer the status of their deliverables. Listen to what they are saying; we micromanage and do not trust the team.
Listening is a skill, one which is can be perfected if practiced.
That's certainly one way of looking at daily stand-up. The other way is that humans aren't perfectly spherical communicators so sometimes daily stand-up really does manage to bring up blockers for the manager to actually resolve.
>> Another example is when product and/or engineer managers use "stand-ups" to ask each engineer the status of their deliverables. Listen to what they are saying; we micromanage and do not trust the team.
> That's certainly one way of looking at daily stand-up. The other way is that humans aren't perfectly spherical communicators so sometimes daily stand-up really does manage to bring up blockers for the manager to actually resolve.
Good point.
I should have made the example more germane by saying "(always|only) using stand-ups for status updates." My apologies for the ambiguous exemplar.
EDIT:
Speaking of daily stand-ups...
IMHO, there are only two questions which need be asked of each team member in a stand-up:
1 - Is there anything you need from anyone in
order to be successful *today*?
2 - Is there anything you want to share with
the rest of the team?
Any other questions/concerns need to be addressed separately.
> Standard philosophical problem, you're disagreeing about the definition of a word instead of the content of the message.
Perhaps I should have said we have a different understanding or expectation of communication, instead of "definition." For this confusion I introduced, I apologize.
> Clearly you agree with OP about how time is wasted but you're insisting on using different language to express the same idea.
I do not.
Again, as I previously self-quoted:
Most meetings are not about communication. They are usually
prescriptive in form and dictatorial in nature.
OP postulated:
Or maybe we're spending too much time on communicating.
To which I disagreed. OP then opined:
If too much time is allocated then its hard to stay focused
and there's always the next time that can be used to
clarify.
Which is an indirect reference to meetings, not communication.
Finally, OP concluded with:
Cut all the unnecessary meetings and only allocate the
minimum viable time to communicate. Then everyone will be
listening.
Which erroneously correlates meetings with listening. Your original response included:
... we all spend way too much time in useless meetings where
nothing happens ...
Thus reinforcing said erroneous correlation. I blame myself for insufficiently expressing my thoughts on the difference between listening, which is implicit in communication and the topic of the article, and meetings, which are an assembly of people requiring only physical presence.
You're still doing it. Now with "definition" vs. "a different understanding or expectation of"
You are not understanding, perhaps willfully, what people are writing and muddying the waters by trying to make unimportant distinctions about words instead of engaging with the meaning as intended by the author.
Every one of your clarifications has just been a pedantic restatement of what someone else clearly meant using different words trying to make a distinction which is not at all necessary to make.
Clearly I am not understanding your perspective on this topic.
> ... perhaps willfully, ...
Not at all and something I had hoped to communicate by a detailed analysis of the thread thus far.
> ... what people are writing and muddying the waters by trying to make unimportant distinctions about words instead of engaging with the meaning as intended by the author.
Words have meaning and I chose mine carefully. There is no such thing as "unimportant distinctions about words" if the words used have differing meanings and can reasonably be interpreted as conveying different thoughts.
> Every one of your clarifications has just been a pedantic restatement ...
This is one way to categorize my communication in this thread. Another way would be to say we disagree and perhaps have talked past each other.
I guess I still need to improve my listening skills. Perhaps you need to as well.
I don't think "attempting to communicate" - or especially not "attempting to LISTEN" as in the title here - would be the stated reason for many meetings. "Pitching people on your shit" or "making sure shit gets done the way management wants it to" is much more accurate for most corporate dev and B2B/B2C sales/product meetings.
For the typical "agile" process for software:
- standup: this fits, attempting to communicate status and request help with blockers
- backlog grooming: attempting to figure out what to do with artifacts of generally-async communication (tickets from a backlog, either created by you in the past or by others). attempting to fit them into the process best. Communication is often seen as a necessary evil, and this process often goes faster with fewer people. if people bring up questions, there may be some attempts to communicate in explanations.
- sprint planning: work assignment and time management/estimations. similar to above, questions could spark attempts to communicate, but it's not the primary purpose.
- sprint retro: improve the team dynamics and the flow of the process. communication is usually assumed here, but in practice it's "people saying things, they get written down, then the next sprint happens same as the last." there often isn't effective communication to the people who could change things
I think if the goal of meetings was more specifically "we are going to communicate until our mental pictures are exactly the same" you'd end up with faster/better actual work from everyone on the team.
But in big orgs that's usually not even what's wanted. If the plan sucks, but it's a VP's pet project, it's not good for various whole teams in that org to all effectively communicate with each other to realize it sucks but not have the political skills or pull to change the VP's mind...
>> Tonnes of frameworks around this concept, so I won't repeat what others have done ...
> Totally understand, but I would love if the author included links to these other things for articles/etc they thought did a good enough job not to repeat them!
I believe the author identified the primary remedy in the article:
The problem isn't that you need a better system. The
problem is you're avoiding doing the work.
Design-by-Contract[0] is a formalization of this concept and well worth considering when working in code using mutable types. In addition to pre/post conditions, DbC also reifies class invariants (which transcend method definitions).
0 - https://en.wikipedia.org/wiki/Design_by_contract
reply