>"most “full stack” developers have not truly mastered front end and back end"
We need to do something about the default of developer bashing prevalent in our culture. There's no true Scotsman, nobody is 100% perfectly attuned to the latest developments on any surface.
Instead engineers develop along competencies that are required in their work. If you need to deep dive into a backend problem, you'll get better at that problem space. Same with frontend.
Yes there are separate stacks beneath the problem being solved, and yes there's discovery and learning as people spend years in a certain focus - but does focusing only on 1 thing mean that you've attained competency in that 1 thing? Does focusing on both the frontend and backend mean that you can't have attained competency in both?
I personally work with fullstack engineers that are better at frontend than some frontend engineers, AND better at backend than some backend engineers - so the answer here is clear to me.
Came to say the same. I've seen good developers that are working on front-end, back-end, and full-stack.
The key is that they are a good developer. Where they focus usually has more to do with the organizational structure and its values than the engineer. If they are the best in their area, if you move them, they quickly become the best in that area.
Besides when back-end means you work on a web API and frontend means you work on a web UI, is there really that much of a difference? It's not like we are talking about completely different technologies.
Generally web ui and web api are completely different techs. Even when you are talking node.js on your backend(which is only 1 out of many languages used), you still are likely dealing with databases and all kinds of things that aren't relevant in 99% of frontend cases. And when I'm doing backend dev work, which is most of what I do, I never deal with DOM and such. There are HUGE differences.
I can't access TFA at the moment, so I could be off base. Perhaps that quote is a jab at people who claim competency where none exists? I personally know front-end devs who will claim back-end mastery cause they set up a Digital Ocean droplet. I mean it does take a bit of command-line know how that a non-tech person will probably struggle with, but that's far and away from being full stack.
There's a line between falsely claiming a title and the no true Scotsman fallacy. You've accurately highlighted real world application of the term full stack, but the term absolutely does mean different things to different people.
If this is the case, then no one should lend any more credence to the term "full stack developer" than to the phrase "I like to work on all sorts of software" - because it's meaningless.
What I do know is that there are many dishonest types that will say they are "full stack" when they really aren't. Then there are others that will not lie on a resume and say they are, when they in fact aren't.
The reality is that any dev can learn to do both - but hiring managers want it all, now, for free, and with a smile.
All that said - the more disciplines and domains you use day to day, the worse off you are going to be IMO. Sure it's good be a polyglot, but specializing helps to hone and sharpen skills.
This again. Is a doctor in his first year of being a full fledged doctor any less of a doctor than one with 20 years of experience? The more experienced doctor is almost assuredly better and preferable, but both of them are doctors.
This assumption that you have to be a master of the front end and a master of the back end to be a full stack developer is flawed from the start. Have you created economic value with a completed project that you build the front end and back end for (no matter how spaghetti)? Congratulations you are a full stack developer. A shitty one maybe, but one no less.
I don't think your analogy holds up. Theres really no such thing as just a "doctor". Everyone specializes in some field, even if that specialization is in generalization. But doctors who specialize in general cases (i.e. family practice) serve the role of passing you off to the appropriate specialist to fulfill your needs. And in the same way I would expect a highly experienced programmer to know the limits of their skillset and when to delegate tasks.
I can attest that there is a such thing as a doctor. I saw one just a couple of weeks ago. I'm pretty sure she specializes in family practice, but she is a doctor none the less. And she'd probably be be very confused if I told her she didn't exist, or she wasn't a doctor because doctors don't exist.
But she wouldn't be confused if you said she wasn't a heart surgeon, because she's not. She can tell you a bunch of stuff about the heart, she can probably do surgery if she was in a position where she had to, but she's not a heart surgeon and wouldn't claim to be.
So how doesn't it hold up? In no way did OP suggest that you need to be able to do everything on any conceivable project by yourself. There could be plenty things that are outside the scope of any given Full Stack Developer. How would that invalidate all the times when they were not?
Maybe he meant, for example, that a 1st year cardiologist is probably going to be a better cardiologist than a 20 year nephrologist. The OP seems to be insinuating in his medical analogy that only time - not specialty - is the most important metric. Take that 20 year nephrologist: if he had spent 10 of those years in cardiology, I don't think most other nephrologists would say that makes him a better doctor just because his experience was more balanced across two fields. In fact, I think they'd say he was a lesser doctor than one who devoted the 20 years to one subspecialty.
Lesser doctor. That was my point: it is my understanding that covering a wider but shallower expertise in medicine would not elevate a doctor among his peers as much as a doctor who plumbs the depth of one specialty (barring one of the well-recognized interdisciplinary field like sleep medicine).
Depends on your illness, and quality of the doctor, often I've met younger doctors whose up to date knowledge out bests that of experienced doctors who have not kept abreast of their field, more likely through resource challenges than malice!
the analogy with doctors although valid on principle doesn't take into account that you can rewrite buggy code due to inexperience, but you can't undo a brain surgery gone bad.
An experienced physician also (likely) has outdated knowledge. For example they might instruct you to eat a low fat diet, even though that is pretty thoroughly discredited nowadays.
First, it depends on the age of the physician. At some point in the late 90s or early 00s most (if not all) of the medical boards require that doctors continue to take continuing education credits to keep up on changes in medicine. In addition they have to re-certify every 10 years. That was not the case in the past, and older doctors are grandfathered. But if you doctor is younger than 40, they will likely need to re-certify and keep up to date.
Second, the prevailing wisdom on low fat diets are still up in the air. AFAIK, the American Academy of Physicians and the American Heart Association have not changed their positions on low fat diets.
Promoting the low fat diet (or just demonizing saturated fat) is incredibly misguided, there simply isn't (and never was) any evidence for it. It's not surprising the AHA et. all hasn't changed course, they made a terrible error and admitting that is embarrassing and stains their legacy (but their legacy is already stained by any right-thinking person).
I believe the low fat diet will be seen as almost equal to the promotion of radium water for health is seen now. At least radium water only affected small quantities of people. The human suffering caused by the low fat diet is unquantifiable. It's a relic of the Cold War that is unfortunately still alive and kicking.
Didn't really like the article. There's no myth, there's full stack developers and of course, they are no masters in anything, but who is?
Even the person who got a DBA job title and has been working with DBs for decades won't have the knowledge about everything in DBs.
I do pretty well in web development in general: backend(ruby/clojure/go) and react/ember.js in the FE. Can optmize queries well, know a lot about computer architecture, OS etc. And I work with people who are pretty much the same. There's a lot of people who can do the same.
Also I find it funny when he tries to put some figures of years, when it generally doesn't take more than an year to know inside-out a framework(let it be a BE or FE framework) given that you work with it full-time given that you know well another one and has enough experience in software development.
One might say that "ah, but then if you do FE and BE it will always be sort of half-assed". Not really, you can test well, write very organised code and even manage the infrastructure using containers. Nowadays it's very easy to pretty much do everything given that you work in a programming language with an extensive amount of libraries, in the end, nowadays web-development is mostly about glueing stuff while writing good code, everything well-tested and perhaps split-up in different services.
But in the end...
Does it matter? No. What matters is if you enjoy working in the whole stack(or not) and if the company has a role available for you given what you want to do.
Why do you only ever hear about full stack developers in web developer context?
I work in FinTech and trading systems - very high performance and low latency systems. I deal with databases and huge amounts of data too. And I've (as well as coworkers) have hacked together trading GUIs and simple CGI to throw together data visualizations. But none of us would ever call ourselves full-stack and we'd never hire a front-end person who thought they were going to go mucking around the infrastructure. They just aren't good enough. This goes equally to small startup like firms I've been a part of as well as banks.
From what I've seen "full stack" seems to be entirely a web notion. Is it just that the backends are simpler - requiring little more than glueing together some Spring components for CRUD operations?
>From what I've seen "full stack" seems to be entirely a web notion. Is it just that the backends are simpler - requiring little more than glueing together some Spring components for CRUD operations?
Maybe it has more to do with the growing complexity and scope creep on the front end. There is an absurd amount of tools/frameworks/libraries that go into the modern stereotypical web page.
Companies (not the big SF ones) are seeing the complexities of web development multiply and don't want to pretend any different. A full stack developer just does everything they used to pay someone to do half of without much of the salary increase.
There will be people like me who are the sole developer at a small company, but my job role is simply "do all the stuffs". They will claim they are full stack developers too. The same way I am my own Creative Technology Officer, Project Manager, QA....
I just steer away from the bullshit titles that companies generally use to devalue your skill set.
It was probably invented to get a wider range of skills in a single position for a similar price of a front-end / back-end developer position.
It could also be the business is saying they don't want specialists at this time and just need someone to do medium or lower difficulty work in either side.
Full stack is web parlance, but anyone who works with GUIs (desktop/mobile/etc.) is technically a "full stack" dev, and it's common for C# desktop developers to also do GUI work.
The web is a flexible place. When I started writing code for money, I was working up user-facing PHP interfaces to databases, and I was called a back-end developer. 7 years later, doing fundamentally the same work only moreso, I was called a front-end developer and paid 10k less a year. Everything is always in motion.
Especially on teams where you deliver a lot of product quickly, it can be easy to develop and maintain both skillsets.
You hear about it in the web developer context (and especially not in finance) because they tend to have quicker iterative cycles, and therefore may be doing quite a bit more coding. There may also be a cost, corporate maturity and scale component as well. ( At scale, you want to depend on fewer exceptional people, and many more average people, doing average things. Fullstack is still seen as exceptional, and its hard to scale exceptional).
I recently moved into a full stack developer role. Not because I am a rock star ninja coder, but because I am the only developer employee in the entire company. The only difference now from some of my more specialist dev roles is that I spend a lot more time researching things on Google/Stackoverflow etc. So when I hear full stack developer I can help but thinking "So you spend a lot of time on Google as well?" :)
No, I don't. It is certainly possible to become competent web developer over whole stack as long as you don't expect to be proficient in every currently popular framework out there.
Pick a set of tools, learn them well and move laterally/dive deeper when you need to.
I can and have contributed to and/or written bootloaders and kernel drivers and web servers as well as all the other stuff people generally consider part of the the full stack. Does this make me even more "full-stack"?
Nah, it just means that, like every other experienced developer, I've got a "paint drip"[1] distribution of skills. My drip is just a little wider than other full stack developers, but the # and depth of those drips is probably comparable.
And that's what full stack means: you have exposure to the entire range of skills necessary to do front and back end, and are expert in more than one of those skills. But you aren't an expert in all of them, because nobody is.
My title is "full-stack developer". Does that means that I'm the perfect developer? That I am senior is all the technologies that I touch? No.
It simply means that I aim to learn all parts of our stack and do my best to master them. It's not a chore to me. I don't have to kick myself to keep up with design trends and programming trends. I love both of those fields and can't even imagine not keeping up with both side of the coin.
In my team there are some very senior back-end programmers. There's also some very senior front-end developers and very senior designers. Do I consider myself above them? Like some sort of unicorn rockstar? Nope. I'm simply a good support player.
I believe that a good full-stack developer is simply someone who is able to work on all parts of a project and help facilitate the communication between the different fields. This last part is the most important of all.
Ding! That's what we are, we're like outfielders in Baseball. You need great pitchers and catchers buy it's hard to win a game without good outfielders.
> On the other hand, if you’re working in an agency/consultancy where it’s important for security/reliability/maintainability reasons to keep up to date with various areas of front end tooling, database types, AI, serverless, etc, then the answer veers closer to ‘never’.
Well I mean, the fact that they mention AI in the same breath and as though it entails the same scope as frontend tooling seems a bit absurd. People with PhDs in 'AI' spend much of their professional lives keeping up-to-date with a very narrow subfield: "keyword-spotting for automatic speech recognition".
The idea that a 'full stack' developer somehow even encompasses that certainly takes it to the realm of complete fantasy.
But "competent to be usefully productive across the development spectrum", is surely possible.
"Full stack developer" is just a new word for "programmer". "Programmer" could be a role for any part of the stack, you just have to solve the problem in hand and you're good.
If you're good or not, specialist or generalist, that's another discussion.
It would depend on who you ask but I consider that to be truly full-stack you need to be able to work on the UI/UX and design. With that distinction, full-stack isn't a new word for programmer.
As far as I understand it, the argument against self-proclaimed "full stack" developers basically boils down to - there's too much to know.
I refute this. I like to put my job in perspective. Astronauts must be skilled pilots, engineers, and have at least some medical training. Doctors have to be able to diagnose hundreds of different ailments. Lawyers memorize books of laws.
There's no maximum storage capacity for your brain. And constantly learning has been shown to keep people feeling better about their life. So I strive to learn something new everyday, and never limit myself to being a developer who only works on X system or in Y area.
There have been less than 600 people to go into space. I'd agree readily that there are at least that many full stack developers. Talking about the extreme ends of the skill distribution isn't productive.
The role of experience is often overestimated in software shops. It's a management crutch intended to overcome their own ignorance. They don't understand software, but they (think they) understand experience.
The reality is a really experienced dev is not really going to be all that much more productive than a well-managed and mentored junior dev. Sure, there are 10x devs, but really, sheer coding productivity isn't worth as much as it used to be. The 10x dev is going to quickly run out of things to do in most shops.
So what you have here is that sure, a junior dev can be a full-stack dev. He's dividing all his attention between all areas of the stack. He's not massively productive in any of those areas, but he's a hammer you can throw at software issues and be able to expect resolution.
That's what businesses need. Developers that can work on teams. You need just enough experience on the team to where problems one dev can't fix efficiently can be escalated to a senior dev, but there's no need for anyone to 'master' anything. Technology just doesn't work that way. You build your experience as you progress through your career, and you're always learning something new.
In fact, junior guys can be way more productive than senior devs. While the senior devs are thinking heavily about architecture, (while playing ping pong) the juniors are knocking out tickets.
This is "the man" talking. The society/companies need specialized workers to be efficient and effective, and a specialist is more 'stable' than a full-stack engineer, especially when the skills he is good at is not needed elsewhere.
From an engineer's perspective, going full-stack gives us more options. And to be honest, for most of the tasks, we don't need to be an expert to accomplish the job.
I've worked as a software engineer for major companies as a back end developer and as a front end developer at different times over the past few years (though big companies rarely give you the option to do both at the same time; which is a waste). With 14+ years of experience, anyone can be a full stack developer and it can really speeds things up if the company is willing to leverage your skills.
I used to do some part-time (second job) lone web dev, this is why i don't anymore:
>"Maintaining a deep knowledge of both front end tools, libraries, and techniques (down to browser-specific quirks), as well as backend architecture […] requires years of experience dedicated to each in addition to the time to keep up to date with how those areas are changing." //
Basically the time to keep up to date with all the tech is increasing; like a growing snake, it's hard to keep track of both ends, and the middle. Also customers expectation increases as familiarity with the web increases.
My definition of full-stack web dev would be everything front-end including things like icon design and optimisation, handling hdpi, logo design, responsive page layout, SEO, font choice and optimisation, dom scripting, etc. through to in-flight issues such as browser caching, CDNs, DNS, security (certs, etc.); through to back-end reverse proxies, varnish, caching, failover, optimisation, actual production of the HTML (PHP in my case) [edit: not forgetting DB, and it's optimisation and management, I never got as far as sharding or anything tricky], and on to keeping servers updated and running securely (SSH key management, firewalls, backup, etc.).
(And in your spare time you do sales and marketing!)
I think it's near impossible to handle the full web stack now; I'd imagine splitting it in to at least 5 roles.
Their definition of full-stack web dev appears to be just LAMP (or similar). So then you've got at minimum a 3 person team: adding a graphic designer, server manager.
Full-stack elsewhere would be something like back-end, gui design, UX, _and_ packaging/installers for distribution?
Have to agree with the article somewhat. Its very difficult to be great at every part of the stack. Big companies require this as their applications last longer than the usual startups. Backend developers think they are full stack if they can throw HTML and JavaScript on the page. The current state of things is that the front end of things is way more complex and having to consider user interactions ends up being as hard as throwing crud together.
On the other side of things, I know Frontend developers who wouldn't dare touch the backend for any reason. So A full stack developer for most companies someone who is willing to do back and front end development if they have to in order to ship a product.
For myself, if I don't like the backend stack I'll stick to the Frontend of things as that is what I specialize in. If the backend stack looks interesting to me then I'll want to work in it. Fortunately, I got a job at a company who can offer me a stack Im interested in on both the front and back ends.
To me a full stack developer doesn't mean mastery of every technology out there or necessarily deep experience within a limited field, but a person with broad enough knowledge to independently and successfully execute a development process. This stands in contrast with the backend developer who reject any UI work – possibly out a lack of aesthetic sense.
Value is only realised by completed features, so a developer that can deliver completed, value producing features by themselves is a good thing. Teams should aim to have compositions of experts in single fields with developers who know enough in all fields. This way features can be owned by a single developer, pairing when needed.
What's your definition of a "Full Stack Developer", I'd like to have the opinions of people here ?
Reading on Wikipedia, it seems, for someone living on Linux, knowing a full LAMP is... trivial. Configuring a debian box is like riding a bicycle. Once you have some good apache confs in your personal library, configuring apache is a breeze. Configuring MySQL (|mariadb) might need some googling if you want to do it right. Writing some php or python is just like writing software. Maybe adding on top of that some iptables and ssl certs.
I'm hoping for some discussion. I know there are more complicated architectures.
You can't automate the "writing software" part, but yeah. I voluntarily avoided talking about automation because that seems out of scope for "Full Stack Developper" which seems to mean (to me): "someone who knows how sh*t works and computers are not magical". And automation is more in line with sysadmin stuff than dev stuff.
What a ridiculous article. It just takes a lot of experience to become an actual Full Stack Developer. Most developers begin in the front end and then have to claw their way out of that to become back-end developers. But that doesn't mean a back-end developer suddenly forgets everything they used in the past.
Also, there are developers working in smaller companies who have no choice but to be a full-stack developer. It just takes a lot of work. Disparaging the concept just because you've not mastered both ends does not in any way disparage the concept itself.
I've been developing for 10 years. I have never had a team, so I have had to build each stack from scratch, myself, including the research and decision making of each tool to use in the stack.
I've put together about 4 generations of systems in this time, each with entirely fresh stacks. The first was pre-build-tools, so I had to write my own module loaders and bundlers from scratch.
The latest web stack uses containerized deployment in a micro service architecture, sql, nosql, rest, graphql, a jwt-based authentication gateway and a modern front end stack.
You don't need anyone else's signoff to consider yourself for any role. By default, you're the most powerful person in your life, but when you allow other people to tell you what you are, you wind up giving away some of your power. This is particularly true in interviews, where another person who doesn't know you is judging you based on a sliver of who you really are. Your job is to define what you want, then show the sliver that aligns with what the world expects from you.
> “Only an individual who has had exposure to and experience in each of the elements of a stack can truly call themselves a full stack developer.”
This term has always struck me as pretty nebulous. Where does it end? Do I have to have written an ISR, or a bootloader? Probably not, but the term "full stack developer" is unqualified, so how can I tell? No doubt this term is very context-sensitive. "Please guess what this means from what software you can tell our business is probably based on."
A "Full stack developer" is either one of two people.
1. A person starting a startup and they are the tech lead on their website.
2. A person who liaisons with other departments but is still the owner of the project. They know enough to perform the business duties and may ask for help or the system is simple enough.
If your web app becomes big enough it will be extremely difficult to have engineers that know the whole stack but they could have enough to fix most problems and figure out to escalate.
Most frontend is light work except for JavaScript. Can someone please kill this ugly monster?
A few years ago, one wouldn't call themselve a developer if all he/she could is string together a UI.
Javascript took us backwards. UI should be the simpliest part of putting together an app.
Also, People are still writing server side html
wpf, winforms, java, android, ios front ends. So people should stop assuming frontend is only JavaScript.
I used to be a full-stack developer, back when the front-end was jQuery. Once the JavaScript community started going insane with new front-end frameworks every two weeks, and none of the companies I was interviewing with used jQuery anymore, I decided to only be a backend engineer. I don't like working with JavaScript anyway.
I can cobble together a jquery UI for a dataviz using D3 but I hate people and their cussedness. When any one complains about color or fonts I just make it black and white in Courier.
Full stack (web) developers are only on the wane because of the shift towards fancy SPA front-ends. Where UX is less important (vast majority of projects) full-stack is so much easier.
Every time I hear someone say they are a full stack developer I start to assume they have opinions on ARP and Ethernet drivers and CPU microcode and consensus algorithms and good caching strategies and font design and UX. Possibly some semiconductor physics and literate writing skills. Sadly it seems to mean something else.
I've come to the conclusion that the only 'real' "Full Stack Developer" is one who, indeed, knows what the stack is, and how to use it.
Also, the heap.
Think about it - those who don't know these things, and don't care - usually gravitate around a singular technology that lets them ignore the details. Those who do know these things, and how to use them properly, usually don't have any particular focal gravity, and are prone to be more flexible, in terms of tooling and methodology.
To me, the "Full Stack" developer is simply someone who cares about whats happening under the hood. The "millennial developers" simply don't.
We had this same issue in the 70's, 80's and 90's, but of course the tools were moderately different. Where once you had Visual Basic guys who just drag and drop things around to get things done, now you have 'npm monkeys' who, for the most part, manage dependencies and the interconnections between.
If you don't know what a stack/heap/allocator is, there is no better time to learn! The world is so rich because of these things - and if you do get an understanding of your runtime environment, well .. there's always another execution environment for your pleasure. Have at it, hacker!
(Also, its been 40 years: do you know where in the OSI model your application lives?)
I am a millenial and i like your comment, although of course the "stack" that the article mentions has nothing to do with the "stack" you are referring to...
somebody is racist! then again, your comment really doesn't affect me. i'm millennial and i build web applications for a living. i also hack on operating systems and hardware in my spare time. a lot of my peers do the same. it really doesn't have anything to do with the generation you belong to. some people are shit developers some actually care about the craft.
There is very definitely a difference between programming in the 70's, 80's, 90's, and now .. in the 'new millennium'.
Except, there really isn't. You still need to pay attention to the state of the stack, whether its the memory kind, or HipNewTechDeJeur™ kind.
I don't think a lot of new developers learn these things, though. Or else there really wouldn't be a need to describe "full stack developers". In the good ol' days, it was pretty important to know the context of your heap/stack usage - it still is.
We need to do something about the default of developer bashing prevalent in our culture. There's no true Scotsman, nobody is 100% perfectly attuned to the latest developments on any surface.
Instead engineers develop along competencies that are required in their work. If you need to deep dive into a backend problem, you'll get better at that problem space. Same with frontend.
Yes there are separate stacks beneath the problem being solved, and yes there's discovery and learning as people spend years in a certain focus - but does focusing only on 1 thing mean that you've attained competency in that 1 thing? Does focusing on both the frontend and backend mean that you can't have attained competency in both?
I personally work with fullstack engineers that are better at frontend than some frontend engineers, AND better at backend than some backend engineers - so the answer here is clear to me.