Why the term 'T-shaped' is better than the term 'full-stack'
I am of the opinion that the term 'full-stack' is too often misunderstood and is in need of a replacement.
The term 'full-stack':
- What is it?
- What does it mean?
- Why is it a problematic term?
This article focuses on the problems faced with the term 'full-stack', rather than the developers themselves.
What is full-stack?
Full-stack relates to a developer who's expertise touch on the entire stack of an application - whether this is front-end, backend, pipeline or automation testing. However, they are not entire experts in any field, although they may have a preference for which area they enjoy the most.
Full-stack Developer is a title a lot of developers aspire to be, but not me.
Why is 'full-stack' problematic?
To an extortionate number of hiring managers and recruiters, a full-stack developer is someone who is magical. They are experts on the backend, experts on the front-end, experts on the pipeline and experts on automation testing, and cost the same as any other developer. So essentially, in their mind, they get 4 developers in one, for the price of one.
This sounds ridiculous, right? But this is what the term 'full-stack' is often misinterpreted as. In my opinion, it can be quite toxic in terms of, developers who are specifically front-end, backend, pipeline and/or automation testers are put at a disadvantage when compared to this misinterpreted term of a 'full-stack' developer.
If you have an application that needs UI, UX and accessibility to be of the best quality, ideally you would get a front-end developer to do it. Similar on the backend, (forgive my lack of understanding on the backend) if you need someone to do some really good database normalisation or to create some really clean API endpoints, you would ideally get a backend developer to do it.
This is not to say full-stack developers can't do those tasks... Full-stack developers are not necessarily experts in that field, they just have decent knowledge and understanding to be able to call themselves backend.
The above diagram is not an accurate representation of my view on a full-stack developer, because ultimately every developer is unique, therefore the central circle could be shifted towards either end and/or it could be morphed/squished, etc. But the diagram shows a clear representation of the difference between a full-stack developer and developers who are specialists in their specific fields.
What is better than 'full-stack'?
Lots of developers aspire to be full-stack, but I don't. I aspire to be a T-Shaped Developer. The name isn't as catchy but it has a more realistic meaning than 'full-stack'.
Think of a 'T' - it has a long vertical line acting as a body and a shorter horizontal line acting as a hat.
The long vertical line acting as a body is your area of expertise - the area you are most skilled at and enjoy the most. For me, this would be front-end development.
The shorter horizontal line acting as a hat is areas you know, but not as well - the areas you have touched on and have a decent understanding on, but may not necessarily know fully like an expert would. For me, my hat is fairly small because I am working towards learning some more backend and automaton.
Again, this is not a fully accurate representation since every developer is different and unique, but I definitely feel 'T-shaped' is a more realistic term than 'full-stack'.
You can consider the horizontal line to be your wide breadth of knowledge and the vertical line to be your depth in knowledge.
Below is a representation of what I feel my own T-shaped knowledge may look like. My main area is front-end and front-end technologies but I have also touched on areas such as C#, Selenium and automation.
I also really like this tweet by @TheAnkurTyagi: