I agree probably 80% or more of your mundane enterprise back-end programming tasks are shuffling data to and fro to the database, batching transformations, system integration and on the wire data transformations. Sure there are the jobs out there where back-end developers are sequencing genomes or creating ML models but for the majority of them, if you need to use ML, you are just the guy pumping the data to some service to get the magic data results. Don't get me wrong, I do back-end dev and it is important, just highlighting that it can be pretty routine stuff.

In those environments front end work can actually be the more complicated system, where a developer is trying to take a complicated manual workflow and capture it into a flow of screens that make logical sense for the user.

What the author is seeing is a lack of team alignment not the division of labor, give that he is a full-stack developer I am sure he is keen to the division, but the problem is a people problem in nature. In the environments I have worked, we do not divide teams into front-end or back-end. Teams are comprised of a mix of skills that are aligned to supporting a business silo. In these team dynamics developers know the value of each of the roles, from the DB admin, to the back-end guy to the front-end guy and what we usually see is cross pollination where many of the *-end developers end up picking up skills from the other side and start working the full-stack.

"At ThoughtWorks, we think of our roles as fluid and non-exclusive areas of championship.

[...]

To be clear, I’m not saying that we all need to be experts in everything. That would be impossible. Today’s technology stack goes down a long way, so being a genuinely balanced full-stack dev is probably not the most realistic of goals — but staying open-minded is."

It's impossible to be an expert in everything, but it's very doable to be competent in many areas. I just don't see the problem in being quite decent,for example, at Vue.js and Kafka and Postgres. Let's say you have been working with Postgres during the last year: you are very competent at it. Now, for reasons, you need to work on the client side app of your company: you don't know Vue.js, but you go and read the documentation (as any competent dev would do). You spent months learning and working on a SPA, and you spent less time with Postgres. Done. Now you're competent at Vue.js (it doesn't take years to get competent with Vue.js, but certainly it takes years to become an expert). You go back to work on your daily tasks with postgres. And now... You have to deal with Kafka. Rinse and repeat. Perhaps then later in 2 years you have to work again in the front end, but this time with React: easy, you already know Vue.js., so knowledge is transferred.

People with no legitimacy trying to make blanket statements like this is an anti-pattern. Frontend is massively different from the backend. It appeals to very different people. I care about scale and performance, not UI work. For me BE is much closer to infrastructure/ops/OS than the JS library of the week. This "full stack" mindset also shows the limited experience of the author. He has no idea of the depth of specialization that some of these tasks include. The fact that he can get away with basic knowledge in both of them just shows the level of the technical challenge in his work. If you are in that context, sure, I even wrote business plans when I had to (and that doesn't mean I think those roles should be merged for everyone), but there's more outside of your knowledge bubble.

I have worked in the past with AngularJS and Vue. The work I produced was similar in quality to the work produced by pure "front end" engineers. I am a generalist, and I haven't seen yet any "front end" engineer doing relational data modelling or learning other language that is not JS