I cannot remember the turning point. Of course "agile" did a lot of damage, then ticketing systems, the illusion that developers are swap-able, and now constant notification stream.
When I worked 25 years ago, I had the same experience. But software was way simpler than today. The scale and complexity of current software requires a level of organization and communication that was not needed with simpler needs.
Most software run on a PC with probably no internet connection. Updating the software required to send discs by mail. Everything was slower, and probably more robust. Maybe banking was closer to what we have now, but it was still slower and there were way less transactions.
In contrast, my last 3 jobs required backend services available 24/7 to serve millions of users worldwide. We had many data providers, and we provided services to dozens of big corporations. We had teams dedicated to just integrate to all the partners, wallets, data providers, etc.
Increased complexity requires more communication and more meetings, and more time dedicated to synch all that development. If anyone wants old-style ways of working, with more time coding and less meetings I would recommend to go to small companies with limited reach. Their problems are going to be easier managed by a few developers that can focus on creating new things instead of getting up to date with all the complexity that a big corporation requires.
Personally i like the fact that there are interruptions at work. Working is often a social business and activities like rubber ducking, whiteboarding or live code explanation with living people works wonders for me. It should happen even more.
The people who were coding 8 hours a day, very often were writing yet another framework that they personally came up with to solve a problem, but without duscussing its requirements. More often than not they were making the wrong thing, making too clever things or over engineering.
This is a very important point, and it's crucial for people to understand that merely making something more available can have an outsized effect.
During my day I try to minimize interruptions by batching them. I will largely ignore Slack, and as notifications come in I glance and determine quickly if it really is urgent or if it can wait. If it can wait, I will punt all of those messages to a "remind me later" of a few hours, and get back to my task. I think this keeps my "recovery time" small as I'm not looking too close at these messages. It's not perfect, but definitely helps over pausing my "real work" to fully dive into each notification or ask.
I’ve built a custom visualization tool for the graphics.
And managers should focus on making people working independently.
Most of the time I just want people to leave me alone so I can get stuff done.
Unproductivity is the little death that brings total obliteration. I will face my unproductivity. I will let it pass through me. When it is gone, only action will remain.
Jump!
The tools for surveilling and enforcing "collaboration" can probably be reprogrammed to measure "flow."
That's something that you learn to do when you have a kid: suddenly, your periods of 4 hours of focus free time (for coding, exploring tech, whatever) during the weekend just _disappear_. You only get max 30 minutes of free time in a day; this is extremely frustrating initially; there is no boss to complain to, no meetings to blame, no solution but to deal with it. Progressively, you learn to switch tasks much more efficiently, by making regular check points, so that you can get interrupted any time and get back to deep work _quickly_.