The post The Myth of the T-Shaped Developer appeared first on Kill All Defects.
Exploring Generalization and Specialization in Developer Careers
Recently a younger developer I respect expressed a somewhat common concern. In essence, their concern was that they were finding themselves doing a little bit of everything and not specializing enough. They were specifically concerned that nobody would want to hire them without a key specialization.
They also mentioned the idea of a “T” shaped developer who has a wide breadth of experience but a specific area that they are deeply skilled in.
Keep in mind that this was a new developer who had recently graduated from a bootcamp and that specializing early on can be both hard and limiting.
This is a common concern for new developers and so, in this article, I’ll explore the pros of cons of generalizing, specializing, being a so-called T-shaped developer, as well as introducing the term “comb-shaped” which I believe is a more accurate picture of a developer career.
Generalization
Generalizing means having just enough skill at a wide array of things. As a generalist, you’re competent enough to wade through issues all over a technology stack, work with a wide variety of projects, and jump in and help out where needed. This means that you’re able to do a lot to help a team and are more likely to take features from beginning to end.
This flexibility in turn tends to result in more things coming your way. You may get bugs assigned to you because people trust you will be able to identify the broken area and will have the familiarity needed to fix things in those areas. Additionally, your ability to get involved quickly in codebases makes you a leading candidate when the business needs to move someone onto a project to help out. This increases your value to the organization, but it can be frustrating and disruptive to you.
The downside of generalizing is that you tend to not know the newest practices and patterns of a particular technology layer and are more likely to write sub-optimal code just because you don’t know the best way of doing something or have enough experience to avoid common pitfalls.
Additionally, specialists may look down on your technical abilities because they are seeing you contribute in technical stacks where you are not an expert and they judge you against specialist standards. This perception of your abilities may cause the organization as a whole to respect you less than they should or pay you less than your specialist peers.
Specialization
Specialization offers a chance to really explore and become an expert in certain technologies and areas. Subsets of larger frameworks, front-end or back-end code, data access layers, communications logic, etc. are all technical areas where people can specialize. Additionally, people can specialize in larger organizations on specific projects or specific types of projects, though this is not frequently viewed explicitly as a form of specialization.
Specialists tend to get more complicated changes and more complicated bugs. They’re more likely to be labeled as experts because their role requires expert-level knowledge in a specific area. This expert-level skillset results in rarer skillsets and can command higher pay as fewer people in a job market have the needed expertise for senior-level roles.
That’s not to say that specialists must be senior developers. Junior developers can also specialize in certain areas and often get forced into this by organizational needs. This can help junior developers gain skill and comfort more quickly, but limit their usefulness to the larger organization or team.
Specialization has its downsides, however. As a specialist, you are much more dependent on a specific technology. If this technology declines in popularity or suddenly becomes unsupported for a major platform, you are likely to be suddenly forced to compete with other specialists in that area who are looking to adapt their careers to account for the sudden change.
Alternatively, if you stick it out when others move on, you can win some very lucrative roles maintaining old technologies no longer in active development, but bear in mind that it becomes increasingly difficult to find jobs that need your skillsets over time and you will lose respect in the eyes of other developers as you are seen associated with an ancient technology.
Specialists also miss some opportunities in organizations because their skills are so narrowly focused. It can be hard to get promoted or moved to another project if there isn’t another person around with similar skills who can pick up your work. This means that specialists don’t see as much variety and don’t get to move on to some of the newer and more “fun” projects organizations might create.
That said, being extremely skilled in a specific area can be a lot of fun for a simple reason: It’s fun to be really good at something.
The T-Shaped Developer
A “T-Shaped” developer is a term you’ll hear thrown around. This simply refers to someone who has the breadth of a generalist and the depth of a specialist in a specific area.
T-Shaped developers tend to arise out of a generalist diving deeper into a specific area they find they have an affinity to or from a specialist branching out and learning more areas.
Most developers will become T-Shaped by the time they hit senior developer, but I do not feel that this is an end-state for most developers. Being T-Shaped is not bad, but I don’t think it’s truly reflective of a modern development career.
The Comb-Shaped Career
Instead, I’d argue that as developers age and gain more experience with emerging technologies, they become closer to something more “comb-shaped”. That is to say that they have the breadth of a generalist and multiple specializations that they’ve gravitated to throughout their career. Additionally, the “base” of the comb is thicker or deeper than the traditional depth of a generalist.
All of this is to say that as developers continue to develop and grow and encounter new libraries and technologies, they amass a lot of areas of specialization and a greater degree of comfort in areas they still are generalists in.
The multiple specializations they have carry some interesting benefits. Because different disciplines and technologies look at different techniques to solve their problems, you can often borrow some specific tools and techniques from one specialization and apply them to other specializations. This isn’t always a literal reapplication of the same technology, but more recognizing a common principle and applying it in a new context.
As you become more and more comb-shaped you will feel a greater degree of familiarity when working with newer technologies, be able to apply new things quickly, and feel a greater sense of general wisdom for software development.
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.
Directing your Own Path
So, next time someone suggests that you should specialize more or that you should be more of a generalist or more of a “T-Shaped” developer, take it into consideration, but don’t fret that it’s an irreversible decision. Your career is your own and, if you stay in development, you’re quite likely to move back and forth between times of specialization and times of generalization.
If it is helpful to anyone, here are the ebbs and flows of my own journey thus far:
- Started as a Java generalist
- Moved to a .NET generalist fixing bugs throughout a codebase
- Pivoted to a WPF specialist writing very involved and complex high-performance controls
- Leveraged that T-Shape to become a senior developer
- Gained an additional specialization in web services
- Generalized more into ASP .NET web development
- Specialized as a Silverlight developer
- Branched out into Angular as a true “full stack” developer as Silverlight rapidly fell
- Specialized more in Angular as we needed to make up some complex ground
- Changed jobs to become more of a .NET generalist and manager
- Specialized in software quality and technical debt management to help my organization meet its needs
Life is a journey and our careers are part of that journey. Pick a path that works well for you and keep in mind that it’s a temporary path that will often rejoin other major roads.
Top comments (34)
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.
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.
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.
Why?
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.
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.
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.
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.
What did you use to make those charts?
This is just Excel with a bar chart.
😯😲😮😦😧😨😳🤑
Amazing
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.