Ich hoffe, wir werden es zeitnah erleben, dass alle möglichen Prozesse mit Publikumsverkehr durch Automaten oder Terminals ersetzt werden. Es gibt nun schon viele digitalisierte Prozessketten und Anträge, und mangels Geld für Personal wird den Kommunen wohl nichts anderes übrig bleiben, Publikumsstellen auf das Mindestmaß zu reduzieren, und bei den Stellen ohne Publikum ebenso gravierend zu sparen bzw. Dinge zu automatisieren.

In 10 Jahren, wenn nun 1/3 der Bevölkerung versucht hat, in Rente zu gehen und die Versäumnisse der vergangenen Regierungen Realität werden, wird es echt eng, und es wird dann in wenig bevölkerten Gebieten rigorose Einschnitte in allen Lebenslagen geben.

Vielleicht ist das auch eine Befreiung aus dem zwanghaften Selbsterhalt, wo sich an alle Arten von Wohlstand und Haben um jeden Preis geklammert wird. Vielleicht ist das eine notwendige Konsolidierung. Mehr Effizienz, weniger Drumherum. Technokratie!

Over course of the last decade, I learned how to align my way of thinking with getting good coding quality.

We live in days where people assume that complex problems must be solved by "simple" and contemporary solutions - like a smartphone app, or WiFi-enabled thingies!

But people, as human as they are, obviously again have illusions (and notable incompetence) about both technical and contextual complexity.

Example: Having Germany's NINA app instead of SMS Cell-Broadcasts

In the past, there were some good things. SMS is (kind of) one of them. Despite it being de-facto insecure nowadays, it features a simple feature and well-defined feature called cell broadcast, which allows spreading messages to all sorts of smart- and dumbphones for maximum reachability.

Why on earth did responsibles not consider this to be a first-hand tool for catastrophe communication?

Yes, officials aren't easily convinced by proper solutions because it doesn't take more money than necessary they're difficult to implement.

And I guess, that already is the answer. But even despite the money reason, why aren't folks just willed to pursue lazy approaches? Using well-established technologies and approaches.

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?