Cover image for A mythical full stack developer

A mythical full stack developer

evgenyk profile image Evgeny ・1 min read

How full is your stack? It really depends.

I have friends deploying real-time systems to chips, and know developers writing artificial intelligence code, there is somebody submitting code to Linux kernel or nodejs, and somebody is creating a to-do app right now.

For whatever reason I never understood this notion of a full stack developer. On the other hand I don't believe in front-end developers, or back-end developers or whatever end developers either.

A good developer could figure out what is needed and what's the best way of doing it. In my mind, measuring people by skills is reducing their potential usefulness to a box we want to put them in.

One thing that is more important than discussing stacks is becoming really good at figuring things out on the fly.

Technology will evolve, there always be new programming languages and frameworks. You might want to stop chasing the latest tools and rather become excellent at figuring stuff out.

Posted on by:

evgenyk profile



Enthusiastic amateur. I write code and play tennis.


markdown guide

On the fly Developer. Not the developer you want, but the developer you need.


Short, to the point, and all too true!


Fullstack nowadays is just another way of saying "we want to pay less for more".


As someone who has written automation tools, applications in JS frameworks, worked in ASM, C, and Go but on the other end has also written a lot of PHP, Perl, and Python. Thank you...

Languages are just tools.

Some jobs require certain concepts (Like front end design vs systems design) but that's about it the tool doesn't matter and as a developer you should be able to learn everything you need to complete the task.

If the task is best completed in BrainFuck and you have the budget to do it in that, then you better start learning BF!


I'm on the fence, to be honest. A mechanic is a mechanic and most likely knows a lot about completely fixing a vehicle. Yet there are a lot of mechanics who decide to specialize in repairing transmissions or even just everyday repairs like brakes and oil changes.

To be fair I think the term "Full Stack" is just a way for developers to advertise to non-developers (i.e. recruiters and employers) what it is we "specialize" in.


"Full stack" is everything though and by nature, one cannot specialize in everything. It's more like the medical/psychology term Not Otherwise Specified, used as a qualifier for X condition or disorder that doesn't fit into any one existing category. At that point, it would be better to simply say Developer.


Well no Full Stack is not "everything" by nature. Full Stack implies you know a Front-End Web Language, a Back-End Server Language, and a Data Store.

Then, by definition, it isn't "full".

That's the thing though, there really is no "official definition" for any of this. That's why developers are so conflicted on this issue.

And that's the danger of using such terms, I believe. "Full stack developer" isn't meaningful, any more than "rock star developer" or "ninja developer". It's just terms cooked up, probably by some HR person somewhere, to make the job sound more glamorous than it is.

We need to be using terms with meaningful definitions, such as "web application developer" (the whole gamut, further defined in the job requirements), "web application UX developer" (a.k.a. what some people mean by "frontend"), "web application database developer" (a.k.a. what some people mean by "backend"), and so forth. These mean something.

Even so, it's odd that we fragment our trade so much. A developer who knows how to use CSS, JS, and SQL is a developer who knows how to use CSS, JS, and SQL, there's no need to call that anything else. I know C++, Python, and XML, but I don't have a fancy term for myself. Such odd naming might be marginally useful in titling job listings on Indeed, but let's face it - developer by any title can wind up needing to work on anything.

Anyway, "full stack" does rather seem to carry the odd implication that nothing exists outside of web application development. It's the current fad, but it's only the top six inches of a very deep iceberg, so saying "full" is pretty dismissive of the rest of the industry. I guess if you had to use the term, call it "full stack web developer" and leave it at that.

You're right, when you boil it down it's just marketing/HR slang.


Well, not everyone is good at everything all at once. Some are great at figuring out algorithms and math functions, others at seeing that one pesky pixel that is out line. Another observation is Java Developers and Javascript Developers are two different animals.


I agree half way. Front and back ends are two different animals and both have to be taken down differently. Some prefer one over the other, therefore the distinction of front/back end developers.

But I do agree that we all need to be able to perform efficiently on any end to get things done.

That being said, I find it funny when "full stack" developers show their pride as if they are masters, senseis at writing code. We are ALL full stack developers to some measure.


I'm proud enough to call myself a Full Stack developer but humble enough to know that means I'm not a true master of any one thing or even any one stack.


It's almost like they should have "problem solving schools" instead of code schools.


I don't agree that frontend/backend/full-stack developers 'don't exist'. A frontend developer is someone who is an expert in building web frontend. A frontend developer can learn new languages or tools and become a backend developer in a short period of time. Labels aren't permanent, but they are a useful and succinct way to communicate what you do.


I think it's more a way to communicate what you enjoy doing, rather than a rigid skillset.


Can you get really good at something you don't enjoy?


I tend to approach development similarly to the OSI layer model. I think it is helpful to know the layer below you and the layer above you, but you really don't need to know every detail of every layer in-between


Some developers have a large depth of knowledge on a few topics, some developers have a large width of knowledge across many topics. Some developers have a large depth of knowledge on a few topics and a large width of knowledge across many topics. But it's very difficult to have good depth the higher number of topics that you add. A developer only has so much time to devote to increasing their width or depth of knowledge.

If you ask me to work in a topic that I'm completely unaware of right now, it's going to take me a hell of a lot longer than someone who's familiar with the topic, versus someone who's an expert in the topic. Sure, I can probably figure it out, but it's not going to be the best solution, or it'll take me a lot longer to come up with the best solution.

I'm more of a "wide-width, expert at few topics" sort of guy.


The divide between frontend and backend developers is correlated with the notion of horizontal slicing. We find that we can be much more effective by slicing vertically if not under time constraints, because what we produce in a unit of work is also testable and, most importantly, provides business value by itself. This can only work out if everyone is at least willing to work in styling code, frontend code, backend code, infrastructure code.


Yes. A programmer is here to solve things. The frontend/backend is more to divide work or give you the choice to do what you like. Also do you wannabe good at many things or expert on a few? I love to learn new stuff but companies only want an expert on one thing.


Google it, understand it, get the job done


I would not recommend to give a task for numerical high performance and vectoization on a backend to a Web Front-End developer - or other direction.


Yeah, I mean I don't want to be only a front-end developer guy who can't play in the backend and vice versa.


I wrote a similar post on LinkedIn with some of the same thoughts and wanted to share.



Agreed, but the distinction can serve to know what the programer enjoys more or how big the learning curve will be. As in any generalization there are exceptions.


We used to call this "Software Engineer". Maybe not something the folks with the iron rings supported but the spirit is there... you Engineer code, you should be able to engineer any code.