Define 'Full-stack'

2018-08-06 , 8 minutes read, 602 views 0 comments

Show size full stack

Let's say, that just like I did some time ago, you decided to become a full-stack developer. You've heard this term multiple times, especially on job offers... You already know, like everyone, that such person should be able to successfully perform tasks on every layer of a web application. Is there something else that you should know?

Full-stack, full-stack everywhere

In almost every single offer I receive on my LinkedIn profile or even a private email - for at last couple of months - there is that word mentioned!
The Full-stack.

This title received some mythical powers lately - it’s often next to words like a “ninja” or “awesome” and even “unicorn” or “badass”. And few years ago, it was just a “Software Developer” - sometimes, even preceded with a word “any”! 
Maybe I’m just crazy - so let’s do a quick sanity check. 


Looking on Google trend reports you can quickly see, that “full-stack developer” phrase became more and more popular every year in the  last five years period. Also, if you look on famous Stack Overflow Developer Survey, for both 2017 and 2018 year, you will see that not only this phrase is widely used, but also many developers consider themselves as indeed full stack developers:

Both surveys allowed to select as many roles as you wish, so they don’t sum up to round 100% - but still, a large portion of surveyed developers (10,696 in 2017 and 92,098 in 2018) selected that they are full-stack developers.

So - we already know, that full-stack is popular buzz-word in the web, and many programmers consider themselves as full-stack developers. In the following chapters, I will try to explain the reason behind this fact, and what it means for IT business in general.


What “stack” is

Full-stack phrase suggest that someone with that role should probably have a wide spectrum of interests - it literally means, that programmer specializes in... all of the “stacks”, right?

And what “stack” is? In simplest terms I can imagine, it’s a set of tools. Tools that we use to build different parts of our web applications - and because of that,  we commonly associate them with application layers. In general we can distinguish broad stacks like:

  • stack (tools) to build backend (server side) of application,
  • stack (tools) to build frontend (client side) of application.

Of course, we can go deeper - and we can split each of these into more detailed stacks:

  • Backend
    • Ops-related (example tool: Docker),
    • Business logic (example tool: Ruby on Rails),
    • Databases (example tool: PostgreSQL),
    • ... more.
  • Frontend
    • UX/UI Design (example tool: Sketch),
    • HTML and CSS (example tool: SASS),
    • JS Engineer (example tool: React),
    • ... more.

And probably we could, once again, go even deeper with each of these subtasks as well… Still - we can treat web development as a root of our knowledge/mind map, splitting into categories that get more and more sophisticated, and require more specialized knowledge and different tools.

At certain level, it will be hard to group given stack to more general groups we’ve selected earlier - for example - where would you place version control skill? What about Java Script if you are Node JS developer? Most likely, they both match equally backend and frotend stacks. That brings us to important point: 

Technologies or skills can overlap between stacks.


Around 2008 you wouldn’t say that about JS - would you? But now you can write backend and frontend using JS. Importance of single page applications increased lately, so JS frotend frameworks are way more important then it was few years ago. 

At the same time, you would probably consider hardware as one of the stacks - because back then, no one heard about Docker or containers, and virtualization was one of the cool and trendy new skills to have. You needed to know something about hardware and servers maintenance for successful deployment - because many times, you needed to install manually your app on real, physical device, that was kept somewhere in the company.

Now - it’s not that important, you don’t care much about underlying hardware, because you use all of these great, easy to use deployment tools, and store your app in the cloud service. That brings us to second, important point about stacks:

Importance of stacks change in time.
Some of them may be gone in few years, and new ones may come in.


Do I need to know all of this?

In many places among the web, I see that people argue that such idealistic full-stack developer doesn’t exist.
It’s a myth, a legend across the industry. You won’t find anyone with such wide skill set. I think that big chunk of these people are developers themselves - because they indeed know how tough it is to advance in all of these areas. Many times they think:
Gawd, I’m working on backend for three years know and I know so little! It would be extremely hard to master so many other areas of web development!” - and they are mostly right.


Indeed, here lies the biggest problem with current full-stack definition (or actually - lack of a official definition) - it doesn’t actually cover how much you need to know from given set of stacks… and from which stacks. In reality, if you would take different developers, and somehow measure their abilities and display them like in RPG game, this is how it could look like:


On these two examples you may notice obvious difference - John has broad knowledge on all of mentioned topics. Monika, on the other hand, knows well only three of them.
Probably John is our fullstack. However - there is also other important difference here - notice that Monika has 8 points in her highest skill, while John has only 5.

That’s reasonable - if they both work the same amount of hours every day, but on different parts of the project, it’s expectable that Monika, focused, specialized frontend developer, will be better in frontend framework, than John, who at the same time needs to work on other problems in his webapp as well.

You may notice something non-obvious here as well - total number of points it’s not equal. That’s not coincidence - John has total of 22 points, while Monika has only 20. Why is that?

That’s because advancing to a new level has higher cost than advancing to previous level (at least in most of RPG games - but I think it makes sense). If you needed 1000 points to upgrade skill of level 1 to level 2, you will now need around 1250 points to do the same for advancement from level 2 to level 3…
I think you get the point.

That makes sense to me, because specializing is hard - it’s easy to jump from one topic to another and have small knowledge about everything. but it’s really hard to stick to one, single thing and specialize in it for years. Sometimes you may work for months and feel that you didn’t get any better, because there was no challenge in these tasks - it was all repetitive, no challenge at all.

You can feel the same when you try to gather deep knowledge in particular field, like a programming language, through books or courses, and get annoyed by the fact that you know most of that stuff, but in one out of 100 examples you'd find something new. Many people don't have enough patience for that.


My definition of a full-stack

For nearly four years now I’ve been working in small software house in GdaƄsk, Poland. I’ve noticed that we don’t really hire highly specialized people. The reason for that was quite simple: company was small, and usually products we’ve been working on were small too (from 1 to 6 people working on given project, most of the time). The definition of a good developer in that company could encapsulate quite nicely in a single hyphenated word:  self-sufficient developer.

Small companies and start-ups don’t have time and money to gather large teams of specialized individuals. In case of small companies, most of the times they don’t encounter sophisticated problems, that may require rare abilities of highly skilled specialist with narrow, but deep technical knowledge.

What they need is a person that’s able to tackle most of things that drop to TO-DO queue by themselves, and it doesn’t matter if this task is in front-end, back-end or in both. Full-stack developer will be able to complete this task - if our John doesn’t have enough knowledge at that point to do it, the developer will educate himself quickly (because he has a broad knowledge at that point - it's not zero)  and resolve a problem sooner or later.
For example, compare previous chart of John abilities with Bob:


Bob has even wider stack than John! However, it’s very shallow knowledge - Bob watched few tutorials about each language on CodeCademy and wrote these skills in his resume. Maybe that’s enough for a trainee, but he’s not a fullstack by my definition - because he won’t be able to fully complete most of the challenges placed in front of him without much, much help from others. Even if he will learn stuff by himself to fill the gaps, it will take much time to do it, probably too much from business perspective. They won't consider him as full-stack, because he won't deliver them value/profits of full-stack developer.

So, from my point of view, the definition of full-stack is:

A full-stack developer is a person with knowledge in most important fields of current web-development to the point, that allows him or her to handle most of the challenges from these areas without being dependent from other team members.

Learning path

That’s the tricky one! How can you prepare for such role? Going by my definition, you will encounter many problems on that journey:

  • Which stacks are important, which are just distraction, and which stopped being valuable? How will I know when they will change?
  • How to avoid going too broad with my stacks or too narrow?
  • How I will be sure  that I know enough from given stack?
  • How I can assure that I’m updating my knowledge from all of these different stacks, so I won’t get behind?
  • How to make this knowledge last?


All these questions are hard to answer, and out of scope for this post. I’ll cover learning tactics for full-stack developer in future posts - stay tuned!



Add comment