In recent years the belief that the only good developer is a full stack developer is adopted by a lot of companies. Most vacancies demand full stack developers but in general the term is not really understood very well.
The stack
With stack we mean the toolset that is being used in order to create software. In a pretty common situation that means a database and one or two programming languages. Often there is one language for the logic and we call that backend (like Java, Python or C). Then we often use a different language for the front end (this can be Javascript, React, Angular and HTML and CSS).
The stack when starting
So when starting a new project without too many environmental constraints most developers will be able to create and maintain the whole application by themselves and you could say that they are full stack since they master the current stack. We have to take in account that however each team member knows the whole stack, not everyone is passionate and good in every aspect of it.
Add some complexity
Well, luckily, nowadays teams have more freedom in maintaining the way they deliver their products. They can test build and release their own applications whenever they think this is needed. This however adds some complexity and knowledge of newer tools:
- They also need to know how to create and maintain their continuous integration and often deployment pipelines.
- They need to know how to set up, run and maintain automated tests, test tools and testdata.
Their stack, the tools they must master, has now doubled.
Add some more complexity
Over time the application might grow and there will be more technical subjects introduced. Maybe things like containers and micro services and they might also start using different types of databases and frontend languages and design systems and such. So the knowledge tends to run a bit thinner now if you expect everyone to know everything. Not everyone has the same interests and often you will see people lean against the stuff they like. Which is great because you often become very good at the thing you like.
This might be a good moment to review the way you look at teams and their outcomes instead of wanting a uniform set of people with exactly the same skill set.
Skills matrix
A thing I used quite a lot is a thing called a skills matrix. It will help a great deal in the hiring/firing as well the personal growth of each team member.
The end goal of most teams is to translate ideas to software that can be used by customers/users. The skills matrix should contain all the steps that are needed to be able to create and deliver this product:
Depending on the team size I like to have at least one overlap per subject so anyone could on vacation or leave for another job without us having to stress over it. I like to prevent people working in the evenings and weekends as much as possible.
It could also mean that you also have subjects that are so specific that hiring specialists could be the right approach.
I have seen too many occasions where a team was not able to deliver due to a person being on vacation or just having a day off. No more: ‘There is no front end developer on Friday’
The stack in an enterprise
So imagine the enterprise architecture nowadays and ask yourself whether it is possible or even a good idea to ask people to know all bits and pieces?
Full-stack in practice often means two things:
- You opt in for a population of Jacks of all trades, masters of none,
- In the real world you will spot them just as often as you would spot unicorns