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.

Software Engineer Skills: Graphic representation of a skillset

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.

Graphic representation of mountains, hills, and 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.

Graphic representation of an employer choosing a developer with a broad and shallow skillset over one with a deep and narrow skillset

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.

Understanding the Basics

What is a knowledge base?

It’s the set of a developer's technical skills, such as languages, frameworks, tools, etc. Two common types are deep/narrow (few expert skills) and broad/shallow (many skills, no domain expertise).

About the author

Tiberius Florea, United Kingdom
member since July 28, 2017
Tiberius is a full-stack software engineer who has worked for Google (Search, Maps, Translate) and interned at Facebook (Ads, Site Integrity) and Microsoft (Speech Recognition). He enjoys cross-functional collaborations with PM and UX as well as solo projects, and is always eager to build new skills. He earned a Bachelor's degree in Computer Science from Brown University and won awards in international programming competitions like the IOI. [click to continue...]
Hiring? Meet the Top 10 Freelance Software Developers for Hire in November 2017

Comments

Gamaliel Espinoza Macedo
Good
James C Russell
It makes a lot of sense in the permanent job market, but may I feel like the situation in (esp. short-term) contract projects is quite different. That is if you have your stable clients who you keep getting projects from, it can surely work. If there is some kind of more formal job search & hiring process, very few HR people think about it this way. And as a dev, if you need to market yourself, you have to consider what the usual requirements are. Of course, you can be a generalist and market yourself in a different way (as long as you have enough dept in any area). And really, throughout the career you are always faced with things like "Anyone here worked with JS? (think 10 years ago) / "Who can fix an IE 6 bug?" / "The Docker guy left, how do we change the deployment pipeline?" and so on and so forth. Just being in the industry long enough forces most people to broaden up. Still, it's a good point and a nice read!
David Lannan
These are very good points. I have found this to be true myself. Contract roles (esp short term) tend to be very targeted. The longer permanent roles being broader. But I like the article. Its very relevant.
Rayhan Ali
When I hire I look at concepts rather than skills. Like OO is a broad concept that covers everything. So it really doesn't matter whether someone learned it using javascript, or even perl with mason or java or C++. Programming is still an art and very few are good at it. Finally big names like fb and Google doesn't matter. I have met worst attitude there with very little to show off. Can you forget COM/DCOM and J2EE technologies concocted by best of brains from many leading industry experts? Or recently angular 1? J2ee security is still so messed up that I have to throw baby with bathwater and instead switch to node js or spring if I cannot avoid java.
Tiberius
Thanks for your comment, Rayhan. Concepts rather than skills: totally agree with you; hopefully the article makes that clear. :) Big name companies: When it comes to how skilled their engineers are, I'd say there's a wide range. Re: their tech and products, they've all made plenty of mistakes, but they've also invented things we can't live without. My point, though, was the ideal career situation is to be both in the freelancing and the traditional employment market.
Tiberius
Thanks, James. There definitely are differences between the contract & traditional employment markets. However, with the rise of remote work it seems to me like the distinction between the two is becoming less clear. Also, as brokers like Toptal get better at what they do, the level of trust between employers and contractors should increase. Few HR people think about it this way: Right, but maybe that's not optimal and it could change. Maybe there's money to be made as an HR person with a better understanding of tech skills. One can only hope...
Tiberius
Thank you, David. Yes, there's less trust and time commitment between clients and developers in the contract market, but I do think that companies like Toptal are doing a lot to solve that problem. And (see my reply to James) I'd argue that the two markets are starting to merge to some extent.
Tiberius
Thank you, Gamaliel.
vikram kumar
Thanks for sharing your insights. I am sure it will help many in their skill acquisition journey.
James C Russell
Why is it a "problem" though? The approach makes a lot of sense and I strongly consider myself a generalist as well, but implying the other one is a problem that sounds a bit too strong. Besides, I don't think that's true, TopTal is great for many reasons, but when it comes to this, I don't see a difference from elsewhere (which is neither good or bad, just a fact in my eyes). Same is true elsewhere, I don't see a change (if anything, it's probably the other way round, since no one advertise for a full-stack devs these days anymore) and I don't see it good or bad, it's simply how it is. I'm no expert on trends in IT, this is just my own experience, so don't take it too seriously either ;)
Tiberius
Hmm... sorry, by "problem" I just meant "a question raised for inquiry, consideration, or solution", not "a source of perplexity, distress, or vexation". But now that you mentioned the other sense of the word, I do think clients generally prefer more time commitment, and both clients and developers want to be able to trust the other party. I also didn't mean to say that Toptal is doing this better than other freelance marketplaces. Toptal's the only one I know, I'm happy with how things work here, and I think they'll keep improving in the future. If the competition is doing things equally well or even better, great for them! I'm also not an expert in IT trends, so I could be totally wrong. :)
Tiberius
Glad you enjoyed it, Vikram.
Richard Cochrane
Thanks for a great article Tiberius. One of the things that I think has helped me a lot is learning a different framework. Having learned Django first, then Ruby on Rails and now Pyramid (with an open look at each's strengths) allows you to identify and understand abstractions - how frameworks are trying to solve the same problems (routing, presentation, models, controller logic) and how they succeed (and where they struggle) against other frameworks. This allows you to understand new frameworks fairly quickly because of an understanding of what to expect, to see the dots that you will need to connect where junior developers can't even find the dots.
comments powered by Disqus
Subscribe
The #1 Blog for Engineers
Get the latest content first.
No spam. Just great engineering posts.
The #1 Blog for Engineers
Get the latest content first.
Thank you for subscribing!
Check your inbox to confirm subscription. You'll start receiving posts after you confirm.
Trending articles
Relevant Technologies
About the author
Tiberius Florea
Python Developer
Tiberius is a full-stack software engineer who has worked for Google (Search, Maps, Translate) and interned at Facebook (Ads, Site Integrity) and Microsoft (Speech Recognition). He enjoys cross-functional collaborations with PM and UX as well as solo projects, and is always eager to build new skills. He earned a Bachelor's degree in Computer Science from Brown University and won awards in international programming competitions like the IOI.