At Worklytics, I’ve been coding both in JavaScript and on our Java backend. I also do a fair amount of HTML and occasionally hack out some CSS. On most teams this would constitute the “full stack”. I do not believe I am “better” at any of these things than many people who specialize in a particular technology. I do it only because, given our current size, I think it’s important that I remain in touch with the platform, end-to-end.
Agility. It’s easier to be agile with a full stack team. If everyone can take on the same types of work, it’s much less complicated to plan and fits much better with patterns like Scrum, Kanban, etc.
Reduce single points of failure. If you’re a small team and can’t afford to have more than one “expert” per layer / component, then such experts pose a serious risk if they should leave, go on vacation, etc.
Flexibility. Most start-ups don’t know what tools/technologies will offer the best solutions for the problems they’ll face. And most start-ups likely will change their mind about the problem itself within six months. People who bill themselves as full stack are presumably less married to a given technology, so more likely to be open minded about trying something new.
Lack of familiarity can reduce productivity. Having recently used a language, framework, paradigm, etc means more of its idiosyncrasies and uniqueness is in your working memory. You’ll spend less time looking up syntax, waiting for your IDE to autocomplete function names, etc. The “right” approach for a problem will come more readily, as it will be more similar to the approaches you’ve used recently. So spreading yourself across languages can lead to inefficiency, usually in the form of more time spent browsing Stack Overflow.
Using what you know is less risky. It’s likely less risky to rely on an expert in technology A to use it to solve a problem that the experts is certain can be done, than to rely on a generalist who’s familiar with technology B and believes it can be done.
Code starts to look like the “least common denominator”. All languages have syntax and features that cater to certain approaches to solving problems. If you’re jumping across languages daily, you can quickly fall into a habit of using only features/syntax that’s common to all of them. This is easy, it makes the code readable, it reduces time spent trying to mentally shift between languages. But it could be less productive (require more code; more complex code) and lead to suboptimal solutions (with regard to architecture and performance).
Hiring people for the “full stack” has a lot of advantages. It certainly makes sense for small teams / early stage ventures. But as you grow and your business needs become more established, there are certainly productivity drawbacks.
Admittedly, I don’t believe there’s a strong distinction; I’m skeptical of anyone who bills themselves as “full stack”, as most companies stacks look quite different. Apart from very small companies, few people truly traverse the stack in practice. Even if they could, even if they’re working in an “agile” way, it’s natural for each person to gravitate towards particular types of tasks over time.
