There's no such thing as a full stack developer

Tim Evko on February 12, 2019

** If you're a generalist with a full stack title, this article isn't about attacking your valuable contributions to your Team. TLDR: j... [Read Full]
markdown guide
 

I consider the term "full stack" to have a different meaning from most people ( i guess ). I think you can be considered full stack when you reach enough knowledge to be technology agnostic, and use the most appropriate technology to solve the task, even if that means learning something new.

After you get deep into a couple frontend technologies and a couple backend technologies you start thinking by design/architecture instead of language constraints, and that allows you to easily take into any other language as needed

 

"No, Johnny, I'm telling you... you don't exist. You're not real."

It comes across as a bit insulting to invent reasons to tell people why they shouldn't exist.

Just like Johnny, full stack developers do exist, and they fit very specific roles and circumstances.

Where I believe the author has questions, the article jumps to assumptions and conclusions instead of just asking the questions and getting real answers.

 

There are full stack developers, that is, people who can set up the OS deployment and configuration, configure and tune the database, write the backend handling code, and code HTML, CSS, and JavaScript competently with a view to accessibility and design. Generally they began when the web was a lot simpler and just kept up. So 15 to 25 years of experience later, you have a full stack developer.

As you might imagine, such people are not cheap and are rarely on the market.

 

And even that is pretty limited in scope to web dev. What about embedded, systems, kernal, data science, IOT, financial & quantitative...

 

We don't ever use the term 'full stack', but at my place of work we are expected to be able to learn how to make changes to everything - our legacy Delphi application, JS frontends, & JVM lang services. Some people are better at certain things than others, of course, so in that way we still have specialists.

The important thing is that people will always help others where they can. Identifying experts really helps with this, so when a question I can't adequately answer comes my way, I know exactly who to point to.

I don't think it's useful to constrain yourself to 'front end' or 'back end' - all dev work can get complicated in its own way, but I think anyone can learn enough to get by in any language, in any situation.

 

[This is a bit of a hot take - I really enjoyed your piece! I've been trying to refine the below for the last half an hour so please excuse me if it's a little rough or repetitive, but I thought it would be better to submit it now rather than let it sit for five days and then not submit it anyway.]

It's important to me for the health of the team and the application that everybody knows how everthing works to some degree, if only so that when half the team gets the flu the other half can still change the CSS, write tests, talk to the client, etc.

I'm not demanding that the frontend specialist become a JVM performance ninja. But each developer in my team cannot be solely responsible for a single technology.

They must be responsible to the customer. The customer doesn't see a stack; they see a website. The website is either working or it isn't. The customer isn't going to complain about the JavaScript load time, they're going to complain about the website being slow.

It's the responsibility of the whole team to make sure that the website working - that's every layer of the stack. I want to employ curious and motivated developers who are willing to learn outside their area of expertise in order to better support the team and, ultimately, serve the customer.

So, yes, I'm happy to hire the K8s veteran (how veteran can you be in Kubernetes? It's like 5 minutes old!) and the CSS expert, but what's more important than their specialism is that they are more focused on their team and the customer than any particular technology.

 

Thanks David, I really appreciate the feedback!

 

Disagree.

The first point, you can think of different strategies when you are proficient in different domains. Your CSS could be enhanced by knowing various visualization techniques through things like D3 and GIS (mapping). Your Kubernetes could be enhanced by knowing about distributed systems, networking, systems analysis, configuration management, etc.

Second point. You need less full stack developers than if you were to hire an expert in every different area and these developers would be more efficiently utilized. What does the CSS expert do when the UI is completed but there needs to be some back end work or cloud configuration done? What does the Kubernetes expert do when the app is being developed and no services/cloud configuration is needed?

The third point, Full stack developers are generally the more experienced developers and can bring other skills to the table like troubleshooting, QA, mentoring, product planning, and communication, project mgt., etc.

As a full stack developer, I believe (and have demonstrated) that I can perform at an expert level in a technology in six months. That comes with (a lot) of practice in jumping into the deep end and learning to swim when deadlines loom.

 

It takes a lot of confidence to genuinely believe that you can master any technology in six months.

That aside, D3 is a rather large library that can heavily impact the overall performance of your app - medium.com/@PepsRyuu/why-i-no-long...

I have made a career out of fixing performance and front end issues in apps built entirely by full stack teams. There are libraries and tools for everything, and your Kubernetes expert might have a tough time assessing why one of them adds 100kb to your CSS file

 

I didn't mean to include D3 I meant that after using D3 you will know things like what a Dendrogram is and how to use it to visualize a dataset. Knowing this (for example) might give you ideas of developing a similar visualization in CSS.

One thing we might agree on (or not) is hiring. I don't believe in technical tests, take-home projects or really any demonstration of mastery of any particular skill set. When I interview and hire I mainly look for two things:

  1. Does the individual truly love the art and science of software development?

  2. Are they a self-starter? ie. do they go out and learn new software development tools, techniques, ideas, etc. on their own without having to be told to do this?

To the extent that both of those are true, you're hired!

 

I completely agree that a quite a lot of front-end applications that make it into production are underbaked, bloated, error-prone and often inaccessible to folks. I personally think this is due to the dangerous categorization of front-end work as "simple" or "junior," rather than a result of the idea of a "full-stack developer."

Any hiring manager looking for a full stack developer is really just looking for someone who has worked with every piece of technology that the hiring company is currently using to deliver web applications.

This is where I disagree a bit - when my team hires a new developer, we use the term "full-stack" as a goal to be continually worked toward rather than a criteria for entry. Every member of our team is expected to familiarize themselves with the different aspects of the applications their team is responsible for - whether that be on the server, the client, or the infrastructure and processes we use to ship and support software. This helps us collaborate well, and decreases the bus factor in general! As a way to build that familiarity, we all strive to work in the different languages and codebases that make up the system.

That said, we do encourage specialization and highly value expertise! For example, I work on codebases in React and Ruby, but as my expertise is higher in serverland than UI-topia (excuse my silly puns), I lean heavily on my front-end-focused teammates for their experience by pairing and/or requesting their reviews before proceeding.

I agree that no one person can be an expert in everything web-development-related. Everyone's got different strengths - it's up to the hiring manager and team lead to ensure we're building a team whose strengths complement each other; that we don't end up with holes in our knowledge as a group.

 
 

I mostly agree with the above, well said.

Still for small teams/projects "Full stack" knowledge might be valuable in the sense that this developer is not the expert in all situations but has enough knowledge to make decisions on his "field" without calling a meeting every hour.

 
 

Interesting take. I generally agree with you. I had a take on this about a year ago (same title, in fact) that has a bit of a different focus. dev.to/remotesynth/theres-no-such-...

 

This is a better & nicer version of my article. Excellent work!

 

People wearing fedora hats will tell you that you are not a full-stack engineer, unless you are smelting your own copper.

I guess that everything depends on the scale. If your project is highly complex, mixing lots of technologies, and with an over-complicated infrastructure, it will be hard for anyone to be able to understand all the parts.

On the other hand, for instance, in my scale, a lot of Rails developers are "full-stack", in the sense that they can develop a feature entirelly by themseves. That means, from deciding the schema of the database, writing the API, coding React/Redux, and writing the CSS.

Of course, it is good to have specialists, but having people who can do anything is useful as well.

 

and you might just make a better app when you hire a CSS expert and a Kubernetes veteran,

Clearly you are considering only the tech parts, but from a business perspective that makes no sense in most cases.

First you will have to hire at least 5 specialists to replace 2 full stack devs.

2nd you will not find those specialists, your HR will look for at least 1year.

Also they will cost at least 4times more and the app would be delivered later with more costs.

Also you will be suprised but some full stacks are better than the experts at their mastery, just because they learn more and have more experience.

 

A developer with a CS degree may sometimes be more interested in GO, Rust, and Node, than a self taught developer who transitioned into the field learning about CSS in order to change a background color on their WordPress blog. While there’s absolutely nothing wrong with these differences (as both serve necessary purposes), it’s entirely unfair and irresponsible to expect both developers to contribute to the same parts of the codebase with equal proficiency.

I disagree with this. The comolexity of your work as software engineer doesn't have to do with your diplomas. We are made of experience and training/learning. The more valuable engineer/developer is made of a large test/error life: there resides his expertise.

 

I am a full heap developer and I often touch full stack then I become s̶̢̨̢̧̟̬͇̗̜͈̤̓̊͂̌͝͝͠ë̴͖̮͖̥̖̦̰̣g̴̡̢̢͚͍̦͚̞̘̼̑̔̌͐̾̆̅͜͝͝͝m̴̢̤̲̝̦͚̦̗͚̝̗̩͑̏͜e̵̠̯͐̽̃̄̂̉̔̅̔̕͠n̷̖̼̙͈͚͕͎̩̤̙͎̎̾̎͝ͅt̷̛̬͉͎̠̙̫̓̾ą̷͖̠̬̮͚̱̫͒̌͘i̴̛̦͖̮̓͊̓̌͛̀̈́̏͜͝͝o̶͓̘̯͙͕̯̳̦̳̒̐͋͛ń̴̨̘̗͚͔͔͊̄̐̅̏̌́̓̏̀̊ͅ ̸̨̨͎̟̣͚̣̭͈͎̻̀̑͜f̶̹͕̥̮͑̎̓̚͠ȃ̴̧̲̲̿̆͜ų̸̢̻͍̹̹̞̖͔̋̋͑l̶̗̖̯͕̻̮͓̝̈̀͆͛̽̄̈̍̈́͘͘ṯ̸͔̥͕̳͌͂̽̔̀̂̿͊̒̃̈́͘͜ ̵͓̟̘̙̙̺̥̗͂͗̍̂̀̍̐̄̊͘̕͠d̶̢̟̜̼̱̜̲̲͉́͊̈͑̓̋͘͠e̷̺̘̭̳̯̞̠̳̳̹̠͎̙͘v̶̖̱̱͕͚̯̊̐̍̔ẹ̵̔͂̽ļ̴̢̡̠̜̬̤̎o̸̙̯͍͈̣̱̐͗̉̋͐́p̵̛̮̜͍̝̬͖̗̖̞͓̅̾́̋̀̈̊̓̋̀̕͘e̸͙̭̟͈͈̓ͅŗ̴̙̯͓̮̭͙̮̙̬̫̯̗̐̍͂̓̀̈́̓͝

 

Sometimes, full stack developer knows more about the entire product not just the development scope, like product owner ship and QE. Which is very important to mark your importance in the organisation. And it's a myth that a full stack developer can't be a css wizard and kubernetes veteran at the same time.

 

That's true! There is absolutely nothing wrong to be good in electronics and physics, JavaScript and Python. The vision of someone who thinks He needs specialized people for each stack doesn't make it that there shouldn't exit people who are specialized in each stack.

 

Eh, the real issue is that companies are hiring for a role they call full stack, but are hiring the wrong ppl. I've been on teams like that. But there are full stack devs and the stack can very but typically they're comfortable to develop on one or more stacks in any part - DB, API, devops, or front end.

 

I started my career full stack (even including hardware support and building networks), but soon got sucked into that black hole considered "web development" and from there, I journeyed deeper down the rabbit hole named "front end development", where I still happily reside.

While you can be a jack of all trades, I think it's much more stressful, so I prefer specialization over being burned out.

 

I think it is valuable to have a full stack developer from the start for a startup to setup basic processes due to the constrain of budget.

Once you reach a certain size, it is ideally possible to hire more specialised developers when you have more money to hire.

Being a full stack developer myself, I think it's valuable to provide feedback to specialist developers due to the reasoning that we draw from a wide mental models to make decisions.

Take for example push notifications, why must we use it. Since it might not make sense to use it unless we have a strong use case for it which is notifications of new articles or certain discounts or promotions.

Which might be of value to users or readers. If not i see no reason to use it besides gaining eyeballs to sign up for services or views.

Which even if we implement it, we might need to have a set amount of weekly notifications, that is in the range of email marketing.

 

I understand your point. and everyone has a different vision of what "fullstack" is.

I believe that every person has that capacity to do everything and it is a question of time and learning.

what was the "fullstack starter pack"? the web
was: html css JavaScript mysql php. Now it is very complex with so many technologies and libraries.

I like to do everything. web mobile desktop. I'm not an expert on "everything", it's true but that depends on the tools and the type of project. I manage the web part well, I like php java python asp c # (desktop apps only) mobile with android, now I work also with angular, vue node. I have also used mysql postgres sqlserver oracle mongodb.

And you're right, I have not delved into several areas and that has been problematic in certain projects but nothing that could not solve. Yes, it is important to have an expert in the area and solve quickly.

 

That's a nice idea for large dev teams, but the rest of the world has room for all sorts of people.

What about small companies with only one developer? What about people who specialize in escalations, or production support? What about all of the freelancers shipping small DB driven websites every month?

There us certainly value in specializing, but I think the world needs integrators too.

 

Even when you study 5+ years in Computer Science & then work 12+ years in Software Industry, you'll not know everything. But if you are even a least bit curious, then you may find yourself in a position where it's hard to introduce yourself as an expert in a single field.

What if your knowledge level is on a per with the top 0.1% devs in the fields like Java, C, PHP, WordPress, JavaScript, SQL, Shell, CSS, HTML & SEO? What do you call yourself then? A "front end developer"? LOL.

Full Stack doesn't mean you know it all. To me Full Stack is an idea, it shows passion, curiosity and completeness. Most of what you know today will be completely obsolete in the next 10 years. Full Stack means that doesn't matter to you, you can fit right into 99% of the software development scenario within 2 weeks. Full Stack means you are ready for the next level, to be the project manager - to be in the top of the food chain; but at the same time, you'll be able to get your hands dirty with CODE when it's needed or perhaps purely out of the fun of it.

Don't get me wrong, your suggestion has merits, it just doesn't fit into every scenario.

 

Thank you. I was considering writing a similar post, but seeing as I avoid JS altogether, I can't really say much on that front. Well put!

 

I enjoyed reading, I agree there is no full stack developer, considering facts like performance, security, os specifics, networking, domain knowledge etcs.
It's the word "full stack" gives wrong impression. Even Linus torvolds had take time to understand high level application. So as you have mentioned "Specialization is Important" so he sticks to his Specialization so he can clearly isolate and focus on only os specifics. So what these terminology full stack means, it's the knowledge to merge the tasks between different layers and get things done quickly, hopefully isolate after release or redesign. Hmmm this process is not software engineering but it's greedy development forced to make just get things done with reusable frameworks, tools. Now what potentially could go wrong or backfire is the maintenance, security, performance, bug patching, application scalability (definitely) poor core design.
Now good part is first get the things done. This will be great fit for startups who can experience business without investing more time and money.
May be full stack developer should be termed as full prototype developer.

 

oo so those boot camps that turn people in to "Full Stack Developers" are bullshits ?? you don't say.

 
code of conduct - report abuse