The Myth of the Full Stack Developer

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.

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.

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.

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?

It seems to be a very new concept.

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.

1: https://www.facebook.com/notes/kent-beck/paint-drip-people/1...

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.

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.

If you're good or not, specialist or generalist, that's another discussion.

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.

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.

https://webcache.googleusercontent.com/search?q=cache:9mRe-8...

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.

>"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?

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.

lol saying that is equivalent to say that mastering frontend OR backend is also impossible.

The reason of that is the term mastery. Mastery, probably doesn't exist, or at least doesn't mean anything.

Useless article

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.

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

Do I qualify as a full stack dev?

https://github.com/tj

https://github.com/wycats

https://github.com/eviltrout

https://github.com/coding-horror

https://github.com/chrismccord

I rest my case.

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

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.

Of course the specialists will know more about their domain.

But the generalist is more useful in many situations. Both play their role in an effective team.

I sometimes regret starting projects with distinct frontends and backends when something like rails would have sufficed.

I'll get my coat.

Nay sayers ask me any question you like.

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?)