alt Hacker News> When I started working, more than 25 years ago, we had one team meeting per week (1 hour), very few other meetings.
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.
25 years ago internet was as good as everywhere at work and schools in the civilized world and was starting to ramp up in homes. CDs or DVDs were indeed still used for large sets of software and documentation, like stacks of MSDN discs. We even had distibuted source code version control, though it was often only synchronized accross the ocean (e.g. using SERI) overnight.
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.