Ask HN: What is “full stack” actually?
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 ] threadWhy 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.
tl;dr Someone who's familiar with
- Hosting / Server environment (SysOp things)
- Application development (Front / Backend)
Then how to configure/update/trouble shoot the web server and related issues like database performance and mail server errors
A web developer saying they work on the "full stack" means that they both write server-side and client-side code.
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".
A lot of us actually don't even touch the web all day long, not even for fun.
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.
At best full stack just means knowing one level deeper than necessary.
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.
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 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?
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!"
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".
I've never seen guys who grok C, ASM and Perl being fascinated by JS and CSS3.
http://en.wikipedia.org/wiki/LAMP_(software_bundle)
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).
(Btw, now hiring full solipsist developers. I'll find you if I'm interested)
That reminds me how years ago companies were recruiting developers with PHP/MySQL/Flash/Photoshop/CorelDraw, etc...
The term is very difficult to define, because you keep on getting different answers for what the stack actually is.
It's really a question of scope.
What about running and maintaining it?
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.
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 think the simplest way to think fullstack is to think of an end-to-end experience and list all the components.