[arcticfox]

That's great, I think we're totally different types of engineers. I think we'd succeed in different types of environments. I think an environment promoting the principles in your post (specialization, business managers, disdain of "full stack") can be effective, especially in huge organizations.

But I am fully confident that a team of "full stack" generalists can be effective as well. I don't think the idea is "such a harmful concept to the profession of programming" at all.

When you're hiring for a web position, go ahead and hire the guy that has never used JavaScript in his life, and leave the "full stack" people that have actually built things in that domain for me :)

[p4wnc6]

I think "full stack" is actually most harmful in start-ups, and that it's one of the primary inhibitors of growth because it fundamentally doesn't scale and doesn't, even conceptually, make sense once a project becomes large enough to have fractured sub-teams with competing and highly specialized needs. I can understand, but still with some skepticism, having 'full-stack' when you're just a team of 5-10 people still in "garage" mode. But anything at all larger, and especially if you're delivering to real clients and seeking to scale distribution, and it just falls down. Even all of the places that clamor about full-stack and have these big scale distribution problems don't actually do it that way. It's much more of a hiring buzzword / hoop to jump through, and then doesn't correspond to the way the work is actually partitioned or completed, except through lip service and verbal insistence.

When hiring for a web position, hire a web developer or a person whose engineering skill leads you to believe they will solve the web development problems. That's my whole point. Web developer != "full stack". Hire someone else for the database side, and have them work together. The two specialists, say, are worth much more than someone you venerate as "full stack" and make do both things.