Ask HN: What is “full stack” actually?

36 points by serverhorror ↗ HN
I'm reading all those "full stack" topics and can't help but scratch my head.

What does it describe? Is this some common basic term I'm actually missing?

To me full stack would start way down at the hardware design and end just when the computation has finished and (possibly) persisted to disk. A vast field that I can't possibly hope to learn in a lifetime.

Dear HN please enlighten me

87 comments

[ 1.8 ms ] story [ 182 ms ] thread
Most of the time it means backend and frontend programming skills (eg: JS for frontend and Ruby for backend).
As far as I know, "Full Stack" is a misused term for developers who are able to do everything from devops to front-end development/ui/ux design.
> are able to/or pretend to be able

Why would you say this? It's incredibly offensive, and adds nothing to your argument. A full stack dev might not be as good as a specialized dev in any of backend / devops / frontend, but that's just the price you pay for being a generalist. That doesn't mean they 'pretend to be able' to do things.

I keep seeing it as "I don't have any support and am forced to do a number of things poorly." Sometimes it unfortunately comes with a gross misunderstanding of the needs of some part of the stack.
I partly agree with this. Although I'm convinced there are actually people who CAN do a lot of "this stuff" quite good; I'm convinced that most of us mere mortals would be moderate in some of these at best while struggling with the rest.
I would guess it mostly have to do with understanding the complete flow and parts of a web service or page. From the HTML/CSS in the front end, javascript somewhere in between and then how the backend language/API talks with the database.

Then how to configure/update/trouble shoot the web server and related issues like database performance and mail server errors

A full stack web framework might mean a web framework that encompasses an ORM, routing, templating, email, possibly a built-in admin panel, and pretty much everything else that you need to develop a CRUD app. Recently, they might also encompass a front-end toolkit for doing AJAX-y things.

A web developer saying they work on the "full stack" means that they both write server-side and client-side code.

It does not neccessarily imply mastery in all layers of the stack but rather familiarity and often the skills to understand and fix bugs in other areas other than your field of expertise.
In my opinion "full stack" is what all developers actually should be.

15 years ago, it was normal that, as a developer, you know how to administer a server, know how Unix works, know how to setup/debug the database. Maybe know a bit of C.

Fast forward to 2015. Lots of developers are purely frontend developers and don't know how to setup a server, or don't know how to administer the database. This is now the norm. The developers who could do all that stuff (as they should) are suddenly "full-stack developers".

You do realize that not all developers work with the web, right?

A lot of us actually don't even touch the web all day long, not even for fun.

Where did the parent mention the web? I happen to agree with them that developers should be able to handle any level of abstraction, at any layer. But this doesn't have to be with web technologies - not all servers are web servers.
The OP said "In my opinion "full stack" is what all developers actually should be."

It's not what all developers should be. For a lot of us, it would be a complete waste of time to learn technologies that we do not use, let alone have access to.

You can be full stack with various different stacks. I use LAMP, so I am pretty out of date with any .Net technologies. But I would consider myself full stack to an extent.
I have no idea how knowing databases or HTML is going to help someone write embedded code for RC controlled drone. And I am mystified by the idea that knowing ARM asm is going to help but a website, MMO, or tax prep software.

At best full stack just means knowing one level deeper than necessary.

Obviously it means the stack YOU ARE USING, not all kinds of alternative wild technologies that are out there. If you are using something that depends on a database somewhere in the stack, then knowing how to administer that database is definitely something a 'full stack' developer, in that context, would need to be able to do.
(comment deleted)
So a C# .net developer should know what?

Basic .net developer: (1 or more JS frameworks ex: Angular), HTML, JavaScript, CSS, C#, .net, LINQ, ORM(nHibernate), XML, SQL, T-SQL, …

Full stack: That plus, basic network administration (TCP-IP, BGP, routing tables?), basic windows administration (installation, security, back, scripts, deployment, troubleshooting), basic IIS administration (setup, matinee, troubleshooting), basic DB administration (deployment, troubleshooting, backups, clustering, profiling etc.), basic team foundation server administration, ...

Then to get an actual job you should know exactly the correct stack, including whatever wacky tools the team likes…

PS: And people wonder why they have trouble finding good developers.

Well, you may think that standards are too high, but on the flipside, yes: the expectation that you are able to deal with such a suite of tools is also out there. Maybe this reflects on the quality of the stack more than anything else - on the other hand, .Net and C# development is pitched as a reason to not have to know any of those things, too.
The problem IMO is out of the 100 or so developers I have worked with none of them fit that profile and IMO that's completely ok. Granted, I actually cover most of that except the networking side, and know a few other that come close. (Which is probably why I am standing up a continuous integration server today instead of actually coding.) But, it really just seems wasteful as the value of teams is they let people specialize.
Nobody said everyone should be a full stack developer - just that more developers should consider the benefits of becoming more proficient with the layers of the stack with which they're not competent.
So, if you know a little HTML, you can write a simple diagnostic page for your drone, or a product page for it.

If you know a little SQL, you can throw a SQLlite database on the drone to easily track points and query the data of multiple drones being collected.

If you know ARM assembly, you can write optimized math routines for your MMO running on mobile clients, or on low-power boards in a server farm. Or figure out why your web server is crashing in weird ways on your server. Or why certain overflows in your tax software aren't being trapped.

"Full stack" means knowing about the rest of the tools so you can improve things beyond what CodeProject would let you do.

I only hear the term "full stack" coming from people who mean "web developer" when they say "developer", forgetting that there is more to life than web-apps.
While true, it's probably safe to assume that in the context of a "full stack" discussion, "developer" can be taken to mean "web developer".
(comment deleted)
The community needs to stop being so imprecise with language. "Developer" is a broad category, and I shouldn't have to figure out from the context of the discussion what "developer" means. In fact, I often run into discussions where the context isn't there.
At the same time, In consider myself a database developer. A software developer that specialized in database driven apps. This used to involve desktop clients ten - 15 years ago. Now its far easier to go with Django and use a web app for the front end. (So I guess I am full stack no).

I would assume that most decent devs no matter what their specialty will be able to get a very basic HTML page working. Or am I making too many assumptions?

I've been developing professionally for 20 years and never encountered the term full-stack until it was used to describe a web developer who could implement design (not necessarily do the original design work), implement the front-end, and implement the backend. It seems to have now grown in scope to include mobile app development in at least one mobile platform as well as fully client-side frameworks like Angular, Ember, or React (which weren't in widespread usage when the term began to be used much more frequently, as I recall.)

This definition including hardware down to the transistor is just silly, and its the equivalent of non-web devs chiming in with a "Hey we matter too!"

On big complex projects in "classically-organized" enterprises you can be successful for years without writing any html, js, css, sql or doing any administration at all.

As a backend dev you get your data from web-services which are written by the web-services team (or another company) which in turn receives optimized database queries/procedures from the database team. You pass the data after processing to the template/fronted which is is the domain of the fronted-guys.

Deployment is done by the ops team to servers which are administered by the infrastructure department in the data center.

My first job as junior-developer was in such organization and it is quite enjoyable to have experts for every domain to learn from instead a lot of "Jack of all trades, master of none" people. The other benefit is that you can put all your effort in to mastering your particular domain.

The drawback is obviously that you are isolated in your tier and don`t learn as much as if you would do a project "full stack".

> In my opinion "full stack" is what all developers actually should be.

I've never seen guys who grok C, ASM and Perl being fascinated by JS and CSS3.

For me, A full stack developer is some one who has knowledge of ML, Web Design w/ UX, Application Development for web and mobile, Databases and Big Data
There's no fixed definition and I've found that people use it when they're asking for 'broad' skills -- where broad is defined by their own experience (cf. most of the other comments here). For example, most web developers would consider front-end and back-end as 'full-stack', whereas an OS/systems person might consider knowledge of hardware up through kernels into the application layer as 'full-stack'.

It's about as useful as the term 'Ninja' or 'Rockstar' in that it's used when people can't articulate succinctly what they mean (or they don't really want to take the time to do so).

It should really include hardware and electronics down to the transistor level, and higher level skills like UI, architecture, marketing.
it should really go down to quantum physic, thermodynamic and up to philosophy...
It all collapses down to a figment of my imagination anyway.

(Btw, now hiring full solipsist developers. I'll find you if I'm interested)

I guess front-end and back-end technology in the company "stack".

That reminds me how years ago companies were recruiting developers with PHP/MySQL/Flash/Photoshop/CorelDraw, etc...

When I hear the term "Full Stack" or someone working as a "Full Stack Engineer" all I can think is someone who can hack its way through the full development stack when need be in a multitier architecture. I sometimes joke around that when a company says they need a "Full Stack Engineer", they mean they want a "Software Architect" without the title,authority and a higher salary.
I wouldn't call it a joke, at least in the insular world of SV VC webapp companies. I view "full stack" as a phrase the same way I view "we want someone whose passion is programming": they're both indicators the company is looking for people to exploit and pay poorly for the amount of labor expected.
The full stack applicant only needs to know a slightly wider view than what the interviewer knows, which in situations with job ads full of stereotypes and cliches isn't very much. If the ad asks for a rock star ninja full stack expert, make an arduino blink a led, draw a pix of your cat in cubist style, bring both to the interview, its all good. In those situations its usually WAY more important to have gone to the same school, and match demographically.
He could create a (good enough) [software] product alone.
I really like that kind of definition. Maybe I was thinking about that too long:

What about running and maintaining it?

(comment deleted)
In my context, Ruby in Nashville, full-stack has meant you can do front-end html/css/js, backend application code AND the hosting/deployment/linux systems administration stuff too.
You are full stack basically if given a computer and access to server you can build and deploy custom webapp in reasonable time.
This refers to a developer who can eat a large, or "full stack" of pancakes.
1. Start at the top of the stack (nearest to the user, furthest from the hardware).

2. Keep learning about lower layers until you get tired or things just don't make sense any more.

3. Define that as "full stack" and ignore anything still below.

For most people the process seems to terminate somewhere around the kernel/user boundary, much like someone in a boat who's aware of the vast shapes moving below but never gets a clear sighting. IMX a typical "full stack" engineer can manage things like routing tables and logical volumes, understands that context switches and page faults matter, but becomes increasingly unable to explain what they really are to others. By the time you get e.g. to different kinds of cache misses or database/compiler internals (even those are still out in user space) forget it.

TBH I think most "full stack" engineers are half-stack at best. So am I. Twenty years ago the upper parts of a modern stack didn't exist and I could explain pretty much everything in the lower parts from tty to network to disk plus VM/schedulers/etc. Maybe back then I could have called myself a full stack engineer. With today's deeper stack (and my own career progression) I'm down to about half, somewhere in the middle. I don't actually know anyone who's truly full stack any more.

Full Stack in the modern context has been re-defined from what it used to be - its now more referred to in the context of web software development.

But in the 80's and 90's, it used to refer to someone who could handle development at any level of a stack of OS/Framework/API's - from either building their own new API/Framework, to using it, to using others, and so on. A Full-Stack Linux developer wouldn't have any problems busting out the kernel sources to add features/fix/debug, compiling libraries (add/fix/debug), building user-space apps (dev/fix/debug), etc.

But these days you mostly only hear it in relation with web technologies.

I don't recall hearing the term at all in the '80s or '90s; I first encountered it some time in the last decade, around the time people working on web sites started to use "developer" as a synonym for "web developer".
I heard it in the late 80's/early 90's, referring to Unix-based developers who could write a kernel module, device driver, user space daemon, user app - in fact I think I remember it referring to OSI and POSIX at first (i.e. can develop anywhere on the POSIX/OSI stack). I think its risen to popularity in the Facebook-era, but it certainly existed as a phrase and a concept in the 80's/90's.
That makes sense; I had no contact with the posix world back then.
(comment deleted)
HTML to SQL and all needed in between.
I'd say PSD to SQL.
(comment deleted)
Full stack = Frontend + Backend Frontend = Think Consumer. He's the one that uses the backend, typically via browser. In the browser world, you have HTML + CSS + Javascript (add stuff like MVC framework, JS library etc). All these interact with backend to query or persist data on the backend Backend - Think producer. Typically these are your servers. Bunch of those actually. You will have servers to simple serve the HTML/CSS and other assets as well as database to persist data. They can be built on a language of your choice - but these days Javascript since you can write both frontend and backend in the same language.

I think the simplest way to think fullstack is to think of an end-to-end experience and list all the components.