I don't disagree, but this article seems to be aiming at an old problem that we might simply call "bad developers" and/or "bad management". It has never been a

I don't disagree, but this article seems to be aiming at an old problem that we might simply call "bad developers" and/or "bad management". It has never been a good idea to artificially separate front-end and back-end, or front-end design and front-end development, or back-end architecture and database design, or just about any other two labels you care to assign. These things have always been related, and a successful system combined all of its elements effectively. But that doesn't just happen by magic, the people involved have to actually think about it and communicate, instead of dogmatically adhering to some fake silo arrangement that rarely helps anyone anyway. It has never been a good idea to artificially pigeonhole any given member of your team either. Sure, everyone has to start somewhere, so maybe you start as JS guy or DB guy or whatever, but that's for newbies. After even a few years working in this business, no-one who's been paying attention truly has a skill set that is only one narrow field but a bit deeper. Everyone is multi-skilled to some degree, and often with experience people develop deep skills in more than one relevant area. Roles like "full stack developer" or "UI designer/front-end developer" are just somewhat arbitrary labels for people who have a particular combination of skills. People who say that you can't play these parts effectively, or that no-one can possibly keep up with all of that so everything should be specialised, are in my experience almost always trying to belittle someone who has broader and/or deeper knowledge and skills than them, and that's not a very nice thing to do. It's not a very smart one either, from a business perspective. I believe much of the time we would be better off if we just dropped almost all of these specific-yet-somehow-vague titles, at least beyond entry-level positions. You need someone (for a small project) or a team (for anything larger) with enough of each relevant skill available to get the job done, and you need everyone involved to know at least enough about what else is happening to communicate effectively with their colleagues. How you divide things up beyond that is almost invariably, again IME, best done based on the individual people you have available and their personal strengths. As long as you ignore the other common but similarly absurd premise that people working in a huge and highly skilled industry are or should be interchangeable, you can work this way just fine, and then the kinds of self-inflicted damage the article is worrying about simply doesn't happen.