Ask HN: Why companies look for “full stack” developers instead of specialists?
In my opinion it would be a big optimization for companies to have a bunch of specialists able to communicate "at the borders" of their domains using appropriate formalism.
Simple example: instead of having 4 full stack devs, a company could hire 2 backend and 2 frontend devs. Responsibility of backend devs would be to provide necessary data to the "front" part of application, so assuming we are talking about MVC, the common, "border" part, would be routing and view structure, leaving views for frontend devs and model/controller for backend devs.
Is "full stacking" a good practice in your opinion?
40 comments
[ 2.9 ms ] story [ 93.5 ms ] threadOne mistake that gets repeated over and over again is the protocol that is too chatty because the people involved like the idea that, like subroutines, operations should be composed out of smaller operations. Trouble is that distributed calls take 1000x or more longer than subroutine calls and are billions of times less reliable.
Without somebody looking at the big picture, what you'll learn the hard way is that performance, reliability, and security are holistic properties of the system which you won't find localized in any one place.
At smaller scale, strong full stack developers can get quite a bit done in "team of one" mode -- perhaps more than two specialists who have to spend a fair amount of time thrashing out interfaces.
My theory is that most backend developers claim to be "full-stack" in order to get the job even though they really are much more focused on backend stuff. This is because its very hard to learn ruby/python/php/java for web development without learning html/css. Project Managers like having full stack jobs only because they think that can just get somebody to "do everything".
This is also probably a bit of a legacy thing, ~15 years ago the difference between backend and frontend web developement was not as well defined as it is now. A web developer would "make the page look like this with a text field there and a button here" (frontend - html/css/javascript) and then make the form on the page "save the form input to a database" (backend - a php script possibly embedded in the page).
These days development is more like "make the site be a single page app with a responsive mobile-friendly design" (frontend - angular/react/ember...) and make it process data from the user and send it off to external apis and integrate third party libraries (backend - rails/django/.net...) and have a version controlled and automatic way of deploying the code to a multiple servers behind a load balancer (dev ops - chef/puppet for example).
As with any technology, the more advanced it gets, the more need there is for practitioners to specialise.
And sure, I'm interested - but I'm also pretty sure that it may be problamatic that I'm European ;) Nevertheless you can contact me at adam[dot]grzelec[at]gmail[dot]com.
Best, Adam
In principle, the world needs more between disciplines experts and you can see it as a universal trend.
That isn't to say this isn't a necessary evil sometimes. Security and mobile development are two simple examples that come to mind of dedicated specialists that many organizations have.
When it comes to generic development, it is beneficial for one person/team to own the entire stack because often the domain specific problems are where the complexity arises, not in the frontend/backend split.
Once things settle down into familiar pattern and you actually have a good idea of what your workload will look like down the road and what specialists you actually need (as oppose to imagine that you might need), then you can start hiring specialists.
Edit: That being said you should have someone responsible for each part and you can split your team into primary front-end and primary back-end based on their relative strength and preferences. However it's important that everybody has the necessary skills to work on all parts of the product in the beginning.
Most people I know have never really worked in the sort of "specialist" position OP talks about, so most of the time they've already got "full stack" (okay, maybe not FULL stack, but...) experience, so we just run with it.
I work 9-5 for a company where 90% of the devs are "full stack". Rarely are the people who "specialize" actually any sort of expert, instead their skill-level on their weaker side of the stack is just especially low.
At startups in the midwest I've worked almost exclusively with specialist devs. Occasionally in the early days a back end dev might also do front end work but in my experience that's far less common with scale.
While we might not be able to find a senior back end dev with production experience in our preferred language / framework easily locally, we can definitely find back end vs front end at various levels of experience. AngelList is helpful for this.
Front end used to be something you could just do on the side on a whim as a backend dev but as the front end web frameworks have emerged and evolved, and consequently more work has moved to the front end this has changed in the past five years or so.
Unfortunately hit such situations quite a bit at my current workplace...
1. A lot many experts are totally unaware of the other side of tech.
2. Experts charge much more even if the requirement wasn't huge (if freelanced expert)
3. Communication is hard. Communicating with four experts about new systems is much more hard then communicating with four full stack devs.
Also I think our job is often just 75% "here's a bunch of information, figure it out" so it doesn't matter what the material is because you're constantly seeing new stuff. Know a lot about a little, and a little about a lot. It's good to have a focus on something but you should be able to navigate every step of the process, even if more slowly than the person who usually does it.
Doesn't matter that I rolled our whole architecture and infrastructure, did all of the ETL work, can handle security, web accessibility & design, and basically run point on all projects. I use basic, unsexy, reliable tools.
A lot of the new tooling is also maturing and lending itself to rewrites.. while tested boring technologies also let you focus on the solution instead of building a monument of orchestration to yourself.
Your claimed skills, if you can deliver on them, are in high demand by unsexy companies who use those reliable tools.
A secondary problem is that any time you have an interface and people who can't clearly understand what happens on both sides of it, you end up having integration problems. And meetings to discuss the problems. And proposals to solve the problems. And disagreement on who should solve the problems. And future arguments if the solutions are wrong. "Communicate with an appropriate formalism" is the probably the hardest part of software; why would you introduce that if you don't actually have to?
Its curious how the work that full-stack developers could accomplish on the server/hosting, load balancing, database, backend, and front end, has been broken into 6 different jobs.
It's true that they have different skillsets, but you also develop software quite differently knowing how load balancing or other pieces work.
My observation has been a shortage of experienced full stack developers resulted in accepting junior developers who only work on the front or back end while their skills broaden, or deepen.
Many experienced (more than 2-5 years) developers I know have spent a few years at a time working deeply in front-end, back-end, or infrastructure solutions as it might relate to their current work.
Front-end and back-end development focus can be seen as a path to growing one's skills. A developer might grow towards the other, or broader in their existing area.
- starting businesses/(relatively) small businesses that look for someone with the broadest skills possible, this way you employ fewer people to get the job done and have a MVP
- established/historical/corporate companies that already have an established stack that you are not going to reinvent (because of the scale or simply because they wont even let you try) and these companies tend to know exactly what their weaknesses are and they search for way more specialized people to fill those gaps. they also look for "fullstack" devs but way more skilleld, akin to "tech gurus" that act more as lead devs/team supervisors to help out anyone that might run into trouble, so in this case you'd better have some nice work experience.
Anyways, frontend/backend/fullstack, in the end, the pay potential and employability is all about how you sell yourself and nothing more.
I don't know why' you be an either when if you had just learned both you can always work in a company that silos people off. Even though I've always seen it as way less effective.
I'm old enough to have experienced at least 2 full thin-client-fat-client cycles and I'm certain the current one won't be the last (at least it seems to have been a recurring pattern since the beginning of modern computer science).
While the front-end / back-end paradigm might make some sense right now because the technologies used for each of those layers conceptually seem to be quite different from each other I doubt it's really that much of a benefit. On the contrary, it might even be detrimental to effective software development:
I'm not in the business of creating either front-end or back-end code. Neither is useful without the other. I'm in the business of creating value and solving problems with software. Depending on the problem at hand this can involve different tools at varying degrees.
Focusing on just one tool or layer can lead to a potentially harmful mindset. A mindset in which you just throw your part of the work over the wall thinking that it's not your problem anymore.
The arguable benefit of having specialists churn out stuff in their respective layer more quickly than a generalist would quite likely is offset by communication and interface overhead: The difficult problems in business applications nowadays mostly arise at their boundaries. Software development for the most part means communication.
I'd much rather work in an environment where I can touch what needs to be touched to make something work, be it green or a feature. Also, there are so many things one needs to have knowledge over as a developer, it's never a true specialization anyway. On the backend you will have your backend language, the runtime environment, the serialization and service boundaries, as well as the persistence, caching and communication layers to the backing systems. On the front end you will have some aspects of interactive/evented design, domain logic and serialization and communication to the backend, along with perhaps another type of caching and persistence on the front end.
Beyond that the more tightly you can couple and work in front and back, the more effective you can be in implementing cross-cutting feature concerns.
The problem, I think, is that the front end is getting specialized, with enough churn, that it's getting difficult to maintain that specialty along with serious expertise on the back end. In the days of rails and html/css, with a bit of javascript, one dev could handle it all (and honestly, I think integrated systems like rails would be a far better choice for a lot of apps that are going full SPA).
But the interesting apps I've worked on? I remember writing a manufacturing and logistics app that had a lot of linear and quadratic programming, and some fairly complicated database design and SQL, and a more elaborate front end for analysis (applets back then, believe it or not). I was pretty happy to stay away from the front end, really, and I can't see how I could have kept up with what's going on with javascript/SPA frameworks anyway.
Technology also evolves too fast, and a company formed just by specialists will face problems with technology and software engineering processes changes. Having just specialists on a such ever change area is not a good deal. The best is to have a mixed team, formed by specialists and generalists, and in a perfect world, a good organization should be made of men, women, young and old people, natives, foreigns, etc. It's like a sailing crew, everyone is (or should be) really good doing something.
In this ever change world of software building, when hiring a specialist you always think: "If tomorrow this job doesn't need to be done more, what this specialist will do to stay with us?"
All of this is just my opinion, my personal theory. I made it up working 10 years with software engineering and development, and recently bootstrapped 3 companies, and the last years I'm studying administration.
This is a less cynical take than a popular post of mine a year back [1], in which I say:
> The 'full-stack' trend is a reflection of rising, dare-I-say unrealistic expectations, one which the author supports by their recommendations in their blog post. By perpetuating the notion that the only 'true way' to be a good developer is to structure their lifestyle around understanding implementation details behind all the layers of a modern tech stack, they place an unnatural reverence on the mythos of hackerdom while ignoring that software development is not solely a creative pursuit.
> As it stands now, 'full-stack developer' is a euphemism, which in hip new places means 'we want you to live and breathe code, because you will be given vague requirements and expected to deliver the entirety of the solution from the bits moving across the wire to the UI espousing the latest visual design language in less than a month', and in established places means 'we want an infusion of new blood to bring sanity to some legacy code and we're counting on you to debug and fix everything by yourself'.
[1] https://news.ycombinator.com/item?id=12168195