The article seems to consider "full stack" as everything-including-devops. My definition, and the one I feel captures the meaning that I most often see is both

The article seems to consider "full stack" as everything-including-devops. My definition, and the one I feel captures the meaning that I most often see is both-front-end-and-back-end, ie someone who can build a complete application feature. I would expect familiarity with DevOps and cloud componenets, but not mastery, of a full stack engineer. Given this latter definition, which, again, I think is more in line with the usage of the term in general, there is a way to reduce the cognitive load required to do full stack engineering, and that is to cut weight, particularly on the front end. I have an axe to grind here, as the author, but one way to do that is to use a technology like https://htmx.org https://htmx.org, which extends HTML, making it more expressive, and allowing 1990s/early-aughts style full stack development without a heavyweight client side model. It isn't going to allow you to do everything a heavy weight SPA framework would, but most applications don't need that, and almost no applications need that everywhere. The big advantage of full stack development is that a single engineer can conceive, implement and optimize an entire feature without bumping into inter-human dependencies. This can lead to a cleaner, simpler and ultimately more maintainable code base. We should be asking how to recapture this extremely productive mode of technical work, rather than dismissing it as "too hard". It wasn't too hard a couple of decades ago, it doesn't have to be too hard now.