[p4wnc6]

For me personally, I do know Javascript a bit and have worked through some tutorials, built some toy stuff with it. But I think the idea of "full stack" is such a harmful concept to the profession of programming that I won't go anywhere near jobs like that, and would absolutely tell people that I know zero Javascript just to get them to leave me alone.

I think specialization of labor applied to the software stack is actually so much more critical now than it ever has been, and that in truth most places that seek to structure themselves around the idea of "full stack" only do it under some misguided belief that it's somehow cheaper or more efficient to employ people who can supposedly "do it all." It's further dysfunction when you see postings asking for very inexperienced recent grads who are also somehow gurus in 5 or 6 full-stack domains.

"Full stack" is generally an outgrowth of bad management ideas, and sends up red flags about companies and teams that believe it's super important, or that very competent engineers with experience wouldn't be able to pick up the skills they need quickly because they have "never gone full stack on web" ...

I see a few of these kinds of things that are somewhat tied together:

"Doing things at scale" -- but doesn't actually define the scope of their specific problem in the job listing or the interview. They seem to believe there is some singular platonic thing that is "at scale" for all problems and all situations.

"Full stack" -- but list conflicting skill sets for a position, or (worse) basically admit that they have no idea what you'll be doing for them. If you're trying to hire a machine learning Ph.D. with 6 years of experience in Javascript, then something up the hiring pipeline at your company is messed up. The drive to do a ML Ph.D. (generally speaking) is not really compatible with the drive to acquire 6 years of Javascript experience.

"Fast-paced" / "constantly-changing" environment -- The job of business developers and managers is to present a stable double-sided interface. One side faces customers and the stream of business problems that Nature creates. The other side faces the employees who then implement solutions to those things. Yes, you can't control the problems that nature throws at you. But you can control the way those problems are ingested, broken down, analyzed, and presented to the workers who will solve them. When a business punts on this and basically says anytime Nature throws us something tricky, management will just jerk you around under the infinite excuse of "fast-paced environment" then you should have serious, serious concerns about whether those business managers are actually going to be successful, or whether they will show respect to the intrinsic human need for adequate work/life balance and professional respect for your position within the company.

[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.