Cover image for Why the term 'T-shaped' is better than the term 'full-stack'.

Why the term 'T-shaped' is better than the term 'full-stack'.

jackdomleo7 profile image Jack Domleo Originally published at jackdomleo.dev ใƒป3 min read

All my articles are first published and hosted on my blog - you can find this article here. You may also be interested in my tweets on my Twitter profile and my monthly newsletter. ๐Ÿ”ฅ

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.

A diagram representing how a full-stack developer role overlaps other developer roles but are not experts in those areas.

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.

A diagram representing how I think my own T-shaped diagram looks like.

I also really like this tweet by @TheAnkurTyagi:

Posted on by:

jackdomleo7 profile

Jack Domleo


A front-end developer with a passion for UI/UX, accessibility & self-development. Author of levelupyourcareer.today.


markdown guide

Nice ๐Ÿ˜„, But What would you call a guy who is good at both Front End and Back-end like server side programming language and DB ? I think full stack is correct in this scenario instead of just saying i am Software Engineer or Software Developer ?


If it's only front-end, back-end and DB, then you are still missing parts of the full stack. Infrastructure is also part of the stack, and there is other middleware which you should include.

Even if these things are not part of your current project, a full stack developer should have investigated the part to conclude if they are needed now, or in the future.
Otherwise you could say your are a full stack developer when you just create a static website. The webserver, etc., are also part of this stack.


I missed parts of the stack to simplify the article because arguably there could be infinite sections in the stack. But sure.


Thanks, Can you give example of Infrastructure and middle-ware ? Also Can you explain what all a Full Stack Dev should know like front-end, back-end and DB etc... ?

Infrastructure is about (visualized) hardware, network management, storage, failover/load balancing, backups, etc. They are the things that you software runs on but which is not explicitly part of the software. Generally you can switch infrastructure without changing the software.

Middleware is basically every supporting software you use. Like, memory cache servers, message bus, API gateways, authentication servers. Things your software explicitly interacts with. You often cannot change these without also changing your software.

There are no rules for what a full-stack developer should, hence this article. It's a misunderstood term.


Full-stack is fine here. I'm not sure you got my point of the article ๐Ÿ™‚ it's the fact full-stack is so often misinterpreted and that most situations T-shaped is a more realistic approach. It's also that a full-stack developer are not experts in every area, they can do just enough for their job. ๐Ÿ™‚


Great Article Jack!! Really enjoyed reading it :-)
I had been working in an Enterprise for a very long time 10 + years and before I switched to firm that specialised offering services to Start-ups.
In an Enterprise set-up, the roles/responsibilities of a developer are very clear. If you are a front-end dev, you are considered to be really good at being one. The firm wouldn't care for you to learn more as long as you deliver what you were hired for. Likewise for backend developers.
However, things were drastically different in the start-up scene. If there's an opportunity presents itself in an area which you haven't worked before, most often the developers too want IN on that opportunity so that they can acquire as many as skills as they can. The firm would also want you to pick up skills, to reduce cost, since it's primarily a start-up. It is a case of true symbiotic relationship. In my opinion, this was sort of the birth of 'Full-Stack' Developers.
But, the 'T' representation in your diagram, is very accurate. I would probably refer to the line that's vertical to represent your 'depth' in the technology and the horizontal line to be the 'breadth'.
In any case, I hope the hiring managers and HR is aware of what 'full-stack' really means. If not, I always have your article to share with them. Thanks for this great article!!


Thank you for your input Skay! I knew I forgot something ๐Ÿ˜… I'll update breadth and depth when I can.


I like the T Shaped People picture on this article: dandypeople.com/blog/t-shaped-empl...

Because everyone is T shaped, just there might be more little depths than the one big one in the middle. I can make an Angular or React app better than I can make a Python app, but my skills lie more in automated tests than anything else.


That's a really good article! Thanks for sharing. ๐Ÿ™‚


Nice creativity Jack.
An interesting way to look at it from another angle.

To me a full stack developer would be someone who could pick (nearly) any problem from the queue and be able to solve it.

If you start or work in a tech startup, and you're the only, or handful of developers, then you have to do everything end-to-end to make the product work and get shipped. If something goes wrong 3 o'clock in the morning, you have to fix it.

Full-stack is not about being an expert at everything, or even anything (few are really, and the learning never ends). It's about being able to solve problems, no matter what it is, and no matter what it takes.


I struggle with this all the time. Itโ€™s probably a topic that I think about the most during my day. As much as I love working across the whole stack, I also believe that that being a master of one is better than being a jack of all trades. However thereโ€™s many factors that play into this, most specialist developers are hired by big corporations, which may not be where I want to take my career. There is also many other factors, but that would mean Iโ€™ll ramble on for ages ๐Ÿ™ƒ

Do you think as a full stack developer, you can never have the same in-depth knowledge as specialists? Would love to hear your thoughts.


I agree with you where it is more likely larger organisations would take on specialists rather than smaller organisations.

A full-stack developer with a specialism is actually a T-shaped developer? Would you agree? Because the long vertical line is their specialism, while the horizontal line is their breadth in knowledge across other areas? ๐Ÿ™‚


Thank you. I wasn't expecting good responses, I prepared for some backlash ๐Ÿ˜…


But your backslash is amazing. ๐Ÿ‘Œ๐Ÿ‘Œ


Couldn't have said it better, matter of fact I'm going to bookmark this for future reference, thanks for sharing! :)


That's encouraging! Thank you!


If only we could post this on an app where there are a lot of recruiters thinking emoji


Lol well I posted it on Twitter and LinkedIn so hopefully at least some recruiters see it.


Thank you ๐Ÿ˜Š๐Ÿ˜Š