back
▲ 28 points

Ask HN: Why companies look for “full stack” developers instead of specialists?

by r34·9y ago·40 comments·view on hn ↗
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
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.

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.

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.

You can generalize this to a "weakest link" issue. If you imagine splitting things into 100 expert teams instead of just 2, it becomes pretty clear that things will move as fast as the slowest team (assuming a linear chain of dependencies).

Unfortunately hit such situations quite a bit at my current workplace...

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.

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.

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.

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.

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.

I'm at a very unsexy company and it's great, honestly. :)
Those are very valuable skills. Developers who have not had a relationship with an existing code base, or one that is less than a few years old don't know yet the difficulty of rebuilding your world every few years and not really progressing.

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.

I think managers who don't know how to interview strong technical candidates will find it hard to hire people with different skills to what they think they need.And therefore find it hard to see how useful someone who has 5 years Node experience can be in a role where they need someone with two years React for example (I've worked with great Senior developers who transitioned very smoothly from Java Servlets to React). But then again I suppose from a HR perspective,the line has to be drawn somewhere.
If you're in SF, Gusto needs someone like you. https://boards.greenhouse.io/gusto/jobs/188188#.WZxXKEFlCEc
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.

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.
Do you use laravel, interested in moving to Asheville, NC? My company is hiring :)
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

Looking to take someone willing to learn both PHP and Laravel? I'm looking.
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.

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.

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?

Frontend / backend were just simplified examples to preserve compactness of my thread ;)
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.

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.

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.

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

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.

Because it sounds good in theory and on paper but reality is another thing
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.

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

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.

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).
"Full stack developer" is just another way of saying "T-shaped web developer" and T-shaped employees are generally considered ideal.
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.

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.
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.
Because this means they can fire all the other developers and save a shitload of money. Make one guy do the work of ten.
Because they can pay one body instead of 3-4.
It depends on the product being built.