The Myth of the T-Shaped Developer

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.