
Ask HN: Why companies look for “full stack” developers instead of specialists? - r34
In my opinion it would be a big optimization for companies to have a bunch of specialists able to communicate &quot;at the borders&quot; of their domains using appropriate formalism.<p>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 &quot;front&quot; part of application, so assuming we are talking about MVC, the common, &quot;border&quot; part, would be routing and view structure, leaving views for frontend devs and model&#x2F;controller for backend devs.<p>Is &quot;full stacking&quot; a good practice in your opinion?
======
dagw
Early on you don't know the distribution of work. If it turns out that your
workload doesn't split 50/50 front end/back end then half your team will be
overworked and half your team will be waiting for stuff to do. Once you get
going it might turn out that the back end wasn't that hard after all and that
your true USP is your world class front end (or vice versa).

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.

~~~
marpstar
This, and the fact that most companies don't have the luxury of having the
choice. Sure, maybe in the Valley you can find expert front-end and back-end
devs just around the corner, but in the Midwest USA, you take whatever
competent developers you can get.

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.

~~~
tedmiston
Interesting how perspectives differs. I work for a startup where all devs are
specialized (headcount is ~50).

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.

------
BjoernKW
Front-end / back-end isn't a particularly useful distinction in my opinion.
Differentiating between those 2 is just another way of creating information
silos.

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.

~~~
tracker1
Came to say very much the same thing... I've worked in scrum silos where each
person has their own piece. Spent close to 15-20 hours a week in various
design and planning meetings, clost to another 10-15 hours blocked by someone
else's work, and only 5-10 hours a week actually being productive. It was
painful, and I left after a couple months.

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.

------
PaulHoule
I have seen separate teams designing a protocol often end up in tears.

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

------
busterarm
Odd. I'm a full stack developer and I find my experience to be the
opposite...or at least it doesn't matter what your other skills are if don't
have 2 years experience in hot-javascript-framework-X (right now, React). I'm
probably just a bad salesman though, but I just don't feel like I'm very in
demand.

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.

~~~
deedubaya
You're not a bad salesman, you're just trying to sell to the wrong customers.

Your claimed skills, if you can deliver on them, are in high demand by unsexy
companies who use those reliable tools.

~~~
busterarm
I'm at a very unsexy company and it's great, honestly. :)

------
chuck32
I don't think its a good idea because in reality most devs are one or the
other.

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.

~~~
r34
Exactly. I consider myself PHP developer and I would like to stick to PHP
related technologies (I think it's enough there) and maybe things like Varnish
etc. But currently looking for a job it's common to demand backend (PHP + some
DB systems), frontend (damn Angular), server, and some other (Docker etc.). In
my opinion it's not the way. At least not for me. And there was the same
problem for every single company I worked with: lack of common knowledge and
set of common solutions for common problems.

~~~
zackify
Do you use laravel, interested in moving to Asheville, NC? My company is
hiring :)

~~~
r34
Hi zackify :) I used Laravel for a short time in one project. I'm more
familiar with legacy Symfony 1 and have most experience with Yii2. But I think
I'd be ok with any quite "classic" MVC :)

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

------
kharazi
As a co-founder of a software company, I have an experience of 15 teammates
for 4 years. Generally, our projects need a lot of expertise like backend and
frontend but in all times, the weight of our requirements are not equal. In
this situation that we have full-stack developers, we can do various projects
often we do heavy-backend projects and having full-stack developers can help
us to find proper tasks to everyone.

In principle, the world needs more between disciplines experts and you can see
it as a universal trend.

------
dasmoth
Having at least some knowledge of all the pertainant tiers is pretty helpful
when sketching out an architecture for others to follow. When combining
specialists, there's a lot of merit in having someone in a senior position who
can speak everyone else's language.

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.

------
thehardsphere
The main problem with specializing in this way is that it presumes that
"frontend" and "backend" are the correct criteria to start specializing on,
and that they're equally valuable. For many applications this is simply not
the case; usually one is more valuable than the other, and if specialization
is necessary it needs to start within one of those two categories instead of
between them.

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?

~~~
r34
Frontend / backend were just simplified examples to preserve compactness of my
thread ;)

------
ptasci67
I have always found that the most difficult aspect of any application is
nearly always the integration points. Hiring only specialists would probably
only make that more pronounced.

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.

------
edpichler
I think because software engineering is not very mature yet, everybody knows
how low is the rate of projects that ends on time successfully. So, the
process of construction software is always changing, and to deal with this
problem, companies sometimes tends to look for generalist than specialists.

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.

------
geebee
I think it depends greatly on the kind of application you're designing. A lot
of web apps have a pretty simple backend, mainly persistence. If that's the
case, for some small apps a pure back end or front end dev might not have
enough to do.

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.

------
niftich
Expending the effort on designing formal, hard system boundaries (within the
same organization) tends to work less well in practice than it does in theory.
The 'full-stack' trend serves to compensate for this deficiency by making
individual devs feel ownership of a higher proportion of the overall product
up and down the stack. As a related effect, it allows the firm to shuffle the
devs where they're needed the most, theoretically not limited by their
specialization in a particular area.

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](https://news.ycombinator.com/item?id=12168195)

------
kjullien
The way I've always seen and understood it is that there's two types of
companies :

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

------
Blackstone4
Because it sounds good in theory and on paper but reality is another thing

------
j45
Full-stack devs are normal, experienced, and a good practice for a lot of
reasons.

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.

------
iLemming
Companies (should) try to hire people who are willing to work at either side.
Fungibility of the team is more important than an individual's level of
expertise. "Experts" have tendency of having one-sided opinions that in a long
term may delay building successful ecosystem of software projects.

------
DeonPenny
Well the big issue is that in practice people and especially programmer suck a
communicating, especially at the borders. If two people work in parallel to
build one thing the issue is that both people need to know how the connection
works before starting. A fullstack engineer typically is going to be as good
as both the frontend and backend engineer with the benefit of the entire
context of the project.

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.

------
Jemmeh
Better to know how all the pieces work together even if just a bit, your
overall decisions will work better with the entire program as a whole.

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.

------
hakikosan
Because, companies want these "full stack" devs to do all the stuff if they
want them to do, whether it's front end or back end or operations, etc. Also
when devs specialize in some area and become experts they cost more, so full
stack devs are probably cheaper than specialists. I feel like "full stack" is
another B.S. like the "devops" thing that's made up recently (~2008 I guess).

------
Klockan
"Full stack developer" is just another way of saying "T-shaped web developer"
and T-shaped employees are generally considered ideal.

------
codegladiator
IMO:

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.

------
digitalpacman
You know what's worse? Full-stack architects. It doesn't seem very plausible
that someone has all the knowledge in both the now very complicated front-end
and back-end stacks to be a proper architect.

------
sipjca
My thought is that you understand the 'system' better and if you can do that
you will probably be a more efficient programmer for them.

------
bradknowles
Because this means they can fire all the other developers and save a shitload
of money. Make one guy do the work of ten.

------
dabockster
Because they can pay one body instead of 3-4.

------
rokhayakebe
It depends on the product being built.

