Broad vs. Narrow Skillsets: Software Engineering Skills Demystified

Every software engineer has a skillset made up of the different skills they’ve acquired. A skillset is “deep and narrow” if you’ve mastered one to two skills and little else; it’s “broad and shallow” if you can do a little bit of everything without being an expert in any field.

Most of us are somewhere in the middle with a few strong skills, a few average ones, and a lot of gaps. In this article, I’d like to discuss the broad-deep spectrum and to argue that getting closer to the broad end would benefit most programmers.

Breadth and depth are, of course, relative. For example, you could be an expert in web development, or just in client-side web development, or just in JavaScript. All of these are “deep and narrow” skills in some sense, but the last is much narrower than the first.

Also, “deep and broad” and “shallow and narrow” skillsets are both possible: The first means everyone wants to hire you, and the second means you’ve yet to learn anything meaningful at all. Since they’re not very common, they’re also not worth discussing in detail.

Types of Software Engineer Skills and Skillsets

Deep and Narrow

Having a deep skillset means you’re an expert in at least one field.

Take SQL: Let’s say you know everything about relational database theory; the pros and cons of MySQL, PostgreSQL, Oracle, and SQLite; how to optimize queries; when and how to denormalize a database, etc. Clients looking for this specific skill will want to hire you ASAP, and with good reason. You’ll hit the ground running and deliver value like few others could.

However, if the project expands or changes significantly, you’ll be replaced or supplemented by programmers with the skills you lack. Even without major changes, would you be able to suggest architectural changes? The client could be better off with a NoSQL database or no database at all, but your narrow expertise might bias you against these unfamiliar options.

Broad and Shallow

On the other hand, if you’re a generalist who’s not a domain expert, you’ll need some time to ramp up on new projects before hitting peak productivity.

To give an example, maybe you need to do a Python project and you’ve never used that language before. Still, you’ve probably heard a few things about it (dynamic, interpreted, multi-paradigm) and your experience with other languages will make the transition much easier.

The code you initially write might not be Pythonic (with tuples, comprehensions, or generators) but you’ll know where to start. You will make steady progress and your well-factored modules will be easy to improve later. Your broad perspective on technology will give you ideas others might miss.

When the project changes, you’ll be an asset to your team rather than a liability.

Skillsets in the Real World

In geographical terms, narrow skillsets look like tall mountains, and broad skillsets are like plateaus. Using this analogy, typical skillsets are likely to feature a couple of mountains, a hill here and there, and a lot of plains.

A random programmer might be great at SQL and Python, OK at web programming and algorithms, and really apprehensive about most other things, like core dumps, OAuth servers, or native apps. Such a programmer should continue to exploit their areas of expertise, while also finding and filling knowledge gaps.

This strategy is likely to serve them best over the years.

Why Programmers Need to Diversify Their Skillsets

Many projects require unrelated skills combined in unpredictable ways. While broadly skilled engineers could contribute usefully to most of them, an expert’s skill set will match few employers’ precise requirements. That’s not necessarily an issue in the short run, as you only need one job to pay the bills.

However…

Overspecialization is risky. Putting your eggs in one basket might be fine if you can predict the future better than everyone else, but that ability is rare and unrelated to tech skills. Consider the demand for Windows programming skills in our millennium. Or ask yourself: could many of us have guessed the respective trajectories of Android, Flash, Nokia, or Blackberry a decade ago?

Lastly, top employers highly value diverse skills. Facebook doesn’t assign new hires to teams until six weeks after they start. Google encourages internal transfers and runs several rotational programs. Even if you enjoy freelancing, keeping your options open won’t hurt. If you’d ever consider working for those companies, you’ll have to be at least somewhat of a generalist.

Assuming that you’re convinced and want to diversify your skills, how would you do that?

How to Diversify and Improve Technical Skills

You could trade money for skills:

• Accept a lower rate while transitioning to an unfamiliar field. If you’re 75% as productive as usual, a temporary pay cut of 25% is only fair. You’ll bump it back up soon enough.
• Do unpaid demo work with the skills you want while applying for jobs that require them. If it turns out you’re not ready for the change, that’s still a useful lesson to have learned.

You could also trade time for skills:

• Contribute to an open-source project. You’ll get advice and validation, give back to the community, and maybe get noticed by potential employers or coworkers.
• Do a personal project for joy, inspiration, and a change from day-to-day work. For example, I cloned the pre-smartphone Snake game while learning React.

You have to look for learning opportunities, but you can’t do that constantly. For my Toptal interview project, I used Node.js and Backbone, neither of which I had much experience with. It was fun, but the required learning pace couldn’t be sustained for months.

Ideally you’d alternate between long periods of stability (with a steady output and income) and brief intervals when you challenge yourself to learn something new. How often you do the latter depends on several factors, like your current skillset, market demand, and your personal goals.

Why Breadth Is Good for Employers

As far as employers are concerned, deep skills will always be required in some scenarios:

• When there’s little trust or time commitment between employer and employee.
• When catastrophic outcomes (like privacy or security incidents) are likely.
• When esoteric skills are required.
• When the deadlines are urgent and non-negotiable.

Still, many projects check none of those boxes and their hiring managers should consider well-rounded engineers. Many technical skills, such as testing and code documentation, and all soft skills (like communication) transfer. Resilience matters even when products don’t change completely; if the part you hired for stalls, a generalist can work on the next highest priority.

Given the importance of broad skillsets, we should encourage developers to diversify, and we should communicate the importance of broad knowledge to employers who may be too focused on “years of experience” with various fields and skills.

The end goal is a track record of satisfied clients; in addition to hard and soft skills, that proves the engineer’s ability to transition to unfamiliar areas. It’s also a strong incentive for freelancers not venture into new fields before they’re ready to do so.

Striking the Right Balance

When broad skills are undervalued, some good developers are idle and some good projects are understaffed or over budget. Demanding a perfect skillset match is like demanding on-site work, in that it makes it harder to match supply (qualified labor) with demand (rewarding work).

None of this is an argument against domain expertise; it will always matter and be handsomely rewarded. We should just keep in mind that broad skills also matter more than is apparent.