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.
Latest comments (34)
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, 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,...
Great article! This can serve as some sort of guide for developers to determine their status in software development journey.
Thanks
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.
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.
1 word: cobol.
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!
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.
I am coffee shaped.
I would like to read that article.
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.
Thank you!