A lot of things in the article I think most younger software engineers would agree with (I'm mid 30s for context, so around where he seemingly put the divide, definitely not an OG). Almost everyone I've ever met wants less meetings and more time to focus/code. I understand if this may be something that has changed over time but I definitely don't think it's something younger engineers want, even if they do have to deal with it. If anything I think they'd relate most since they've always had to get their work done with less time to actually focus. I also hate the idea of daily check ins/standups and don't like two week sprints, but we don't do either of those and I haven't at previous companies.

Other things mentioned I just don't think are actually true about modern software development, although possibly it depends on your company. I've worked mostly in FAANG companies and we absolutely spend a ton of time on design. And I think this is where collaboration, team cohesion, etc. is so important. The design phase is where you need that communication, then you ideally separate and focus on your own work solo. Then maybe get some review etc. (though like he mentioned, I agree code reviews themselves are relatively pointless, I haven't done one since working at a smaller company). But during the design and somewhat ongoing it can be extremely helpful to know what partner teams and engineers are working on (though daily updates absolutely are not needed).

My biggest takeaway from the article is that he really, really, hates writing unit tests. I see pros and cons for both approaches honestly. As a software developer I would love someone else (dedicated QA) to handle a lot of this for me. I don't know if that's necessarily actually better from a company perspective though (not saying it's not either). It definitely makes scaling tougher for very large companies. Who's QA on a 3 person team (or "group") for example, does every team need dedicated QA? When is it worth having? Obviously that's something that can potentially be solved, but it's not necessarily easier or worth it. My experience though is that at best it's extremely exaggerated to state that unit tests are the main focus these days. In total I maybe spend two weeks a year writing tests, if that.

As for documentation and learning on the job my experience also doesn't stack up, and this is maybe the part I feel like the article comes closest to "old man yells at cloud". You are absolutely expected to constantly be learning and improving on the job and you better have read all relevant documentation. The first thing that happens on any team I join is I'm given pages and pages of documentation to go through. I spend most of my early time on teams literally studying it and taking notes. I think a lot of the "back in my day" quotes in regards to these topics are some of the most out of touch in this article. "We didn't have stack overflow so we had to..." So what? Stack Overflow exists now, people adjust. It can also be a learning tool in and of itself.

Overall I think some of the major points may be true (though as mentioned I don't necessarily think younger engineers would actually disagree with those points). I've never worked at Microsoft specifically so can't say what it's like there, maybe a lot of this is more accurate. I don't think I read very much that I think actually shows a divide between software developers of each generation though, other than speculation that younger developers can't concentrate.