Write sentences that lengthwise match your way of breathing.

Now what about this claim?

Well, it's an idea to keep sentences as expressive as possible.
And hence, as you want to get main points to be understood by everyone surrounding you,
you want to don't want them to get distracted.

So, there's no time for inadequate audible speech interruptions, i.e. breath pauses, caused by expressing prolonged sentences and sentence structures.
And then there's the idea of writing like the way you speak.
Not meaning doing too many orthographic or grammatical sacrifices,
but rather comforting the reader with the way you would talk - while reading!

That said, why not optimize at least written speech to a level where you can 'read' breath pauses?
Between sentences and/or key messages, so no piece of information goes unnoticed.

Despite this way of communication being less likely emotional or doesn't please every asthetic aspect of language,
you tend to communicate subjects efficiently.
At least this is my very experience.

People do forget.
All the time.
Nearly everything.

This has huge and certain effects on how you and others view the world around you.

And codewise, if you program on things all day long, you will likely forget small details after a while.
So, what you might do, is to be prepared.
To be prepared for the lack of knowledge of your future-self.

How to be prepared?

It's like treating yourself and doing yourself a favor, and make everything to be re-learnable really easily.
So in case you need to put hands on an older topic, you'll remember it quick enough - hopefully.

It's also good to pretend that you currently lack precise knowledge, so you act to be as 'unknowing' as possible,
in order to re-explain things to yourself (and now the good or even 'wise' part arises:) or to others, like your colleagues.

What parts then are to be learned repeatedly?

Places in codebases, code conventions & styles, and interface definitions.

So if you name code symbols thoroughly,
put classes in packages where you might search for first when looking them up,
and keep domain logic coherent (read: put each cluster of logic into a separate object or code module), things should go the right way.

I guess these are a few coding principles that some programming gurus may defined as well,
yet I dipped right into coding without great theoretical backgrounds back then - and made these experiences on my own.
(And please just accept my claims here :-))

And most obviously, even learning how to communicate subjects to yourself (and maybe others) is a thing to learn as well, so trying out different things - and failing - is mandatory.

When developing software, consider to name every code symbol, structure or variable to what the symbol should finally represent domain-wise,
not what the symbol is made of or consists of.

We finally have passed the era of unassisted code writing and not-knowing what a m_nWheels variable might stand for, and can finally adapt to things we figured out over the span of the last 25 years.

In an extended search for examples, I'd take a look at classic calculus:
Since the beginning of mathematic and programming teaching,
lecturers tend to be too lazy to name symbols to what they actually shall represent,
and instead resort to layman-uncomprehensible terms.

Instead of a

getOrdinatePoint(whereOnAbcissa)
                    = 2 * whereOnAbcissa + 4

f(x) = 2x + 4

And even later in one's education, where you might learn how to program in Java,
you get to learn your very first example of for-loops:

This way, you wouldn't have to introduce programming newbies the concept of reasonable symbol naming and hence don't likely ruin your year-long well-crafted codebase.

Stop this whole piece of misconception at its roots!
Beware of the wrong kind of laziness and gift awareness for comprehension to everyone.

Why do people attend hour long meetings?
Or even plan them?
Why do they discuss things in them despite no one did ever prepare for a topic?

Because people seem not to know better and often enough don't reflect on how meetings actually are meant to work because there's the next follow-up upcoming or day's end just in sight.

How to plan better meetings with less snore noises and wasted man-hours?

Why not pre-formulate a goal, and then expect a type of result or outcome:
(And of course, you have to do this before the actual meeting, not during the meeting.)

Is it a decision being made?

Is it a question you want an answer for?

Or do you want to hand out information?

And what about team huddles?