The Myth of the T-Shaped Developer

Matt Eland on February 22, 2020

The post The Myth of the T-Shaped Developer appeared first on Kill All Defects. Exploring Generalization and Specialization in Developer Career... [Read Full]
Editor guide

Not sure if there is a difference to comb-shaped, and a term I recently learned from The Devops Handbook, E-shaped. It makes a lot of sense to have multiple specialisations, and also to know more than just the basics about stuff directly related to your specialisations. Ideally your in a team that alligns with your ambition.


I love the term E-shaped. Thanks for sharing!


Good writing, interesting topic! :)

I finished university with a teaching degree (History and English as a foreign language). During my university years, the main mantra was always "Life Long Learning". While I was working as a teacher I told this to my students. Then I switched careers and became a Front-End developer. When I got my first developer job I had a disadvantage, so I did 60 our weeks (I was used to it, because of the workload I had during teaching). 40 hour was my job, and another 20 was just to learn/study new things. Read, watch video courses. 4 years later I'm still doing that.

Although, I don't think categorising skillsets into shapes is the right approach, I think the Comb-shaped path gets closer to Life Long Learning. In the end, being a Senior developer is just having experience facing issues and finding solutions. I might not be skilled in SQL, but I am certain that I can quickly learn it, just as I have done it with Docker, or with back-end development, or with Groovy.

Once I was very skilled with Angular JS, but I wouldn't say that I still am. Although, I am certain that after a little time I would remember things and that part of the comb would rise again. Therefore, I think that the comb shaped view is more fluid. For me, It is more like the sound display used to be on Winamp. Constantly jumping up and down. :)


That's a great picture. I view myself as a serial skills collector.


My manager mentioned the T shaped idea to me a few days ago and I agree it is a somewhat strange metaphor.
I have no idea which shape I am :)
I did dive quite deep into several domains and technologies but every time I switch I have to allow some of the columns in the graph to gradually go down as the technological and business landscapes change.
I have to admit that your depiction of the comb shaped developer comes across as quite stressful to me (not sure that I understood it like you meant it). It sounds like "be better than almost everyone at almost everything" :)


That's good feedback. Read it more as "by the time you've done this so long, you're going to look like this" not "this is what you need to start becoming". Enjoy whatever path you're on. It'll likely change a few times, but that's okay.


I recently made a career change to a new company and one of the main points in their interview process was that they look for T shaped developers. I agree that it's a strange idea when the average developer has so much technology to learn. Playing devil's advocate, though, I think it might make sense to look for a T shaped developer in that company's tech stack or position being filled.

In the general concept of shaped learning, I like the idea of grouping technologies that a developer might be better at in the middle and make more of a Bell Curve.

At this point it's all semantics. Realistically I focus on specific technologies that I enjoy working with and those that I use for my professional position. If someone asks if you're a T shape developer, then go ahead and tell them, absolutely! Cause if you're only talking about 3 technologies or skills, then what's it matter?


See, I don't get the whole idea of looking for a T-Shaped. Where I'm sitting, we all will become a T-Shaped at some point. I think it's a term that becomes something we use as a litmus test and it really shouldn't be.


Because checking if someone is a T-Shaped dev doesn't typically measure how comfortable they are or skilled they are with that breadth, or even how deep their knowledge is at the deepest level.

Why does this matter? What's the fear? That you will always specialize and never branch out? If that doesn't happen and you need it, then part ways then.

If the fear is that you won't have the breadth, then just hire a generalist, or hire a specialist who's very good at growing and willing to learn.

It's sort of like shopping for a new a car based on its highway and city driving capabilities, but not actually buying it because it hasn't driven on one or the other yet.

I just don't get it.


I think looking out for such and such-shaped skillsets is a dead end.
Recruiters should look out for specifically one skill: being able to learn efficiently.
That makes the whole discussion obsolete, since the shape of your skillset can transform and adapt rapidly.


Agreed. The whole point is that it's a journey and things aren't as isolated as we think they are.


Amazing article, thank you. I struggle with being a "master of none" as my career took me from control systems engineering (linear & nonlinear control, research in systems biology), to robotics using pneumatics (R&D, Matlab), to statistical car accident data analysis (R), back to robotics (research, python), to (self educated) frontend web development while taking courses in ML&DL, and then back to robotics (ROS). Now I'm taking a course in fullstack web development (to become a better SW engineer) and DL (because I love math and it's magic) and am looking for jobs.

I love everything I've learned so far, but I have an identity crisis and imposter syndrome since I'm not "very good" at any single one thing.

This article helped me see how my breadth of knowledge and experience can be viewed as an asset 😅


Absolutely. It took some time for me to see the immense value my generalist peers offered to the organization.


Great article. As someone who can qualify as a younger developer (both in age and by the years of experience in the industry), I really thought I should be a generalist specialized in one area. Even though I am a back-end developer I always found front-end development interesting too and I love doing React beside other things.


Important Note: There is no guarantee that by the time you become “comb-shaped” you will have any hair left. Such are the ironies of life.

I feel seen :-) Great article, and something I've been considering a lot lately.


What did you use to make those charts?


This is just Excel with a bar chart.





Great read for someone who is beginning their journey as a developer in a bootcamp. Thanks for posting!


Good to hear! That was my hope in writing it. Which bootcamp?


Flatiron School in the Seattle campus.


great article, but there are also "foundations" that are common to all programming languages and tools, like design patterns, principles, clean code, paradigms (OOP, FP), TDD,...and skills too, that are beyond a specific area, like debugging, version control systems,...


I am coffee shaped.


I would like to read that article.


Awesome message! Thanks for sharing.


Happy to help!


Nice article.
Thanks for sharing.


My pleasure. My friend got a lot out of the concept and I felt he might not be alone.


Even having more specializations you will still have that one single thing you love and excel and spend most of your time. Maybe pyramid shape?


Go deeper on that analogy. I'd love to see details.

Yes, you'll spend a lot of time in a few key areas, and these areas will likely change over time.

Yes, you'll love some areas more than others, perhaps disproportionately to the time you spend on them. I'm definitely this way with desktop app development.

Tell me more about the pyramid shape. I'm curious.


Didn't say all those pongs on the comb had to make sense, be appealing, or not have snapped off long ago. I'm a Silverlight developer myself!


Thank you!


This will be my goto resource when the "T-shaped developer" comes up in discussion.

The T is great visual, however the comb shape paints a more realistic picture.

Thanks for this!


Great article! This can serve as some sort of guide for developers to determine their status in software development journey.


Code of Conduct Report abuse