Poll: What does “Full Stack” mean?
Apparently (https://news.ycombinator.com/item?id=29806385) there is a great divide in what "Full Stack" really means. Since the dawn of man (the full stack developer = man), "Full Stack" just meant frontend and backend development. But now, there is a group of people who seem to be calling it only "Full Stack" if it also includes a set of feature-complete modules for doing the most common tasks, such as ORMs for interacting with databases, a way of handling caching or even reading/writing to queues.
So what is it, who is right, or is there even more definitions out there?
Once this poll is complete, we can hopefully all agree on a common definition.
40 comments
[ 3.0 ms ] story [ 92.6 ms ] threadDev Ops - Backend - Frontend
You'll also be implicitly on-call at all times despite that fact never being verbalized.
I've stopped marketing myself as full-stack because I don't want to be on call. I can (and will) still do the job if needed, but prefer to specialize in my old age.
Imho; a fullstack developer is a person who can develop all pieces of an application (or game, or whatever) and put it in production, maintain it, improve it.
I.e. design the database or other persistence, implement the layers that manages the data, the business logic and the user interface.
It can be very different from different applications, of course, since some may not have an ui, or a persistence requirement.
It is a person who not only knows how to write code, but also understands how code communicates with services and humans.
A fullstack developer understands OS and computing in general.
When I build teams, I like to have a mix of fullstack, frontend and backend developers because the experts (i.e specialized Devs) often handle the nitty gritty details of front- or backend, whereas the fullstack glues together the front-, back- and ops.
Usually fullstackers are the kind of people who say "oh, interesting problem, let's explore" rather than "I don't know this technology, I am a (Fe|be) developer.
You will rarely hear a full stack developer say "I'm unable to continue, because I have to wait for the (dba|integration team|ops team)". They will solve their problems and often has enough experience to do it well.
> You will rarely hear a full stack developer say "I'm unable to continue, because I have to wait for the (dba|integration team|ops team)". They will solve their problems and often has enough experience to do it well.
There are many of us like this who will never take a fullstack role because the reality is, we'd rather work at places that solve that problem by...
- properly sizing the integration/ops/db team for example?
- setting timelines up so that developers aren't blocked as often?
- account for downtime with things like codebase maintenance?
It's not like in theory a company can't have their ducks in a row and benefit from a "fullstack dev"...
The problem is if they're explicitly looking for full stack it tends to be a negative signal.
You should definitely have proper time lines, that has nothing to do with full stack developers.
Downtime? If downtime is an issue for your system, most likely you can build it so it can be live with some parts off and do maintainenance during working hours. (Redundancy, etc)
Integration and dB teams, imo, is an antipattern.
But what I really did not agree with with your original comment was that managers look for full stack devs because of cost.
I look for the right people, and I build my teams with a mix of frontend, backend and fullstack devs. It has nothing to do with cost, it has to do with building efficient and dependentless teams.
Anyone claiming to be full-stack should be able to handle light dev-ops for a small to medium sized company for at least a few days without breaking things. They should be able to sit in any other generalist coder's chair for a week. They should be able to work closely with a designer to help develop the look and feel of the application and have an understanding of the domain tools and language. They should be able to work closely with a DBA to help develop the best database for the application. They should be able to debug complex app behaviour with their understanding of how the different sections work, even if they don't have explicit knowledge of specific areas of the application.
A full-stack "developer" may only refer to the coding and design+UX portions of that description, but should still be very familiar with how the server software and network works. A single framework may provide a full-stack development solution (RoR, for example), but a full-stack engineer needs to cover a lot more ground than just development.
At the lower end of the stack, modern processor/memory performance architecture, beginning with a basic understanding of instruction sets. Ability in some hardware design language would be good, tristates, gates, latches and flops.
But that's just my take on the full stack.
With the cloud it may not matter as much if you've never twiddled SACK settings, but there's a large body of knowledge that is entailed by full-stack that can't be covered in boot camp.
But, an example is discovering from the DSACK responses that your network performance sucks because the intel TCP offload firmware is retransmitting entire jumbograms when any packet gets lost.
Also discovering that you can't get near full network bandwidth because some moron attaches a 3-byte SNAP header.
And if you don't have some idea how your programming language works, how do you know what you're doing? When a memory cache miss costs the equivalent of several hundred instructions.
a colleague described a recent scenario. they've got a college kid (... 1st year? 2nd year?) doing programming work, and basically dissing on all tech stuff that he isn't intimately familiar with (which... means a lot of stuff). he managed to get some stuff working on google app engine, but some of the stuff doesn't work. The kotlin stuff has a warm up time ("that's normal"), but some PHP stuff takes 8-10 seconds all the time for on every request. "PHP sucks, it's shitty, everyone's leaving it, kotlin rules", etc.
No one else is seeing that same performance. Most other people hit the PHP instance and get 100ms response times with moderate payloads. He keeps insisting that it's PHP that's horrible, and what he's seeing is evidence that not even google engineers can make it work because it's so bad.
My colleague and a couple others have said to him "you have a network problem - some route to that app engine isn't working right for you for some reason".
"oh no, it's not that. PHP is crappy".
So... over the holidays, he goes home to parent's house. Has a week of doing some work, never once mention of PHP being slow. IIRC, he seemed to think google got stuff working (despite PHP being crappy). Then he's back at his regular place, and suddenly it's all slow/bad again.
Hrm... if you're the only person on a distributed team having extremely slow network issues to one server, then that problem goes away when you access it from a different network, then you have the same problem when you go back to the first network... it's not the remote technology. Or... at least not the tech you think it is.
I'm not saying he can actually debug or affect an actual fix, but diagnosing/recognizing the signs of network problems as actual network problems should be a requisite. If 8 people hit a server and get 100ms or less response times, and your requests take 8 seconds from your house, but 100ms from your parents' house... this is a network problem on someone's end. It's not a PHP (or kotlin, or ruby, or whatever) issue.
201x - Web Developer
200x - Webmaster
199x - Guy with a computer
That's how I remember it.
Neal Stephenson, Termination Shock
"Over the past few months, I have really started to admire what I call “Full Stack Web Developers”. A full stack web developer is someone that does design, markup, styling, behavior, and programming. Some examples of these types of developers are Jason Tremblay, Geoffrey Grosenbach & Tom Preston-Werner." --Randy Schmidt
The original link is dead, but it's still available via the Wayback Machine. [^0]
I still get a kick seeing people trying to describe what a full stack web developer is and almost every single instance neglects to reference Randy's original post. Let that sink in for a moment and consider the countless job descriptions you've seen in the last fourteen years.
[^0]: https://web.archive.org/web/20110210194715/http://forge38.co...
dunno, maybe it goes deeper.. something about sand, and how it's hard to make even a toaster from scratch*
* https://www.youtube.com/watch?v=5ODzO7Lz_pw
It's tricky when talking about SPAs because while we call SPAs "applications" they almost universally are only thin-client frontends over an API. I wouldn't call the Washington Post's frontend an actual application, nor would I call the Mixpanel UI an application. It gets fuzzier with things like Slack and Spotify.
Personally, when I hire, I only hire full-stack web developers and my expectation is that they're just as comfortable rendering HTML on the backend as the frontend (and they have a pragmatic sense for what is appropriate when), they have no problems manipulating the underlying database schema, they can manage the caching system, jobs system, email delivery, etc. Not everyone is amazing at everything but everyone needs to be familiar and moderately comfortable doing most things, and the team is there to backfill anyone's personal gaps.
- Embedded software/firmware development in ASM/C/C++ (microprocessors, drivers, RTOS, various on-board and external interfaces and buses.
- Various communication protocols running on top of various wired and wireless topologies.
- Developing front-end applications as mobile apps, desktop apps, and web-based apps.
- Developing back-end systems using a variety of architectures (monolithic, serverless, containers)
- Designing and developing entities, schemas, and API's for the system.
- DevOps
- Gluing all this shit together so that it works.
Of course even this is really only 'partial stack', since I didn't do the VLSI design of the 74x series ICs I was using. So when I think full stack, I think high level code all the way down the transistors. Anything else is weak sauce. ;) ;).
"Microsoft Fullstack"
or
"Google Fullstack"
or
"Amazon Fullstack" (formerly "Apache Fullstack", now forked and rereleased)
Underrated comment of the day here.
I interpret "Full Stack" to mean mostly web front-end. It generally doesn't mean mobile or desktop. It does also include back-end development but the trend is to use more off-the-shelf solutions and services so that there's less of it than there used to be. The reduction in back-end coding is taken up with the expectation that the "most commonly used functionality" is now in scope.
+ what other comments say where they want multiple specialists but are hiring one position for flexibility or cost.
I'd prefer something cooler like "1337 hex wizard h4x0r g0d first of his name" but the HR people like full-stack better.