On breadth vs. depth of technical knowledge

Friday’s posting about balancing the value of learning specific technologies and following technologies you enjoy got Jeffrey Thalhammer thinking about depth vs. breadth of knowledge.

Whenever my colleagues and I discuss our career plans and the job
market, someone always asks me whether to learn programming language
X, or operating system Y, or framework Z. But I like to point out
that time spent learning some new skill is also time not spent
honing the skills you already have. And in my opinion, it is both
more lucrative and more enjoyable to be a master of one craft, than
to be mediocre at several of them.

This is because I’ve noticed that those who are the best in their
chosen fields are always fully employed and highly compensated.
Especially during an economic downturn, employers become more
selective about who they hire. So when they go looking for a
candidate with a particular set of skills, they want to choose the
person who is strongest with those skills — not the person who has
the most different skills. And employers are usually willing to
pay a premium for top-notch talent, if they can find it.

I’ve been on the hiring side of the interview table enough times
to know this. When a job candidate shows me they have mastered one
technology, it also demonstrates to me that they have the potential
to master others. But having partial expertise in many technologies
may only prove that they own a lot of O’Reilly books.
Truly mastering any technology requires a great deal of patience
and dedication, and those traits are far more valuable to the team
than being able to write code in 16 different languages.

Having said all that, I do acknowledge there is a real tradeoff
between the depth and breadth of one’s technical skills. Not all
job candidates are created equal, and it just isn’t possible for
everyone to be the “best” in something. I’m sure there is a
sweet spot where you can optimize your employability, and this
doesn’t mean that you should completely ignore other technologies.
The industry is constantly evolving so you must stay up-to-date,
and learning a little bit about other technologies can give you a
fantastic new perspective on the those you already know well. And
of course, this all assumes that you actually enjoy the technologies
you’re working with. If you don’t enjoy them, then by all means,
go learn some new skills.

But if you do enjoy the technologies you work with, then I urge you
to consider mastering those technologies before going off to learn
some new bag-of-tricks. To be sure, the road to mastery is long
and difficult. It is fraught with frustration and can be boring
at times. But it is also challenging, exciting, and deeply rewarding.
In the end, I believe it will lead you to a much happier and more
prosperous career.

I’d rather be the first-pick candidate for just one position than
the second-pick for several.

Jeff Thalhammer has been specializing in Perl software
development for over 10 years. He is the senior engineer and chief
janitor at Imaginative Software Systems, a small software consultancy
based in San Francisco. Jeff is also the creator of Perl-Critic,
the leading static analysis tool for Perl.

Advertisements

4 Responses to “On breadth vs. depth of technical knowledge”

  1. oZ Says:

    Wow, I’m not sure how to start here.
    I really don’t agree with this comment at all, based both on personal experience as an incoming employee and as a hiring manager. I am a huge Perl fanatic and user, been tinkering with the language since 1996 and using it for gainful employment since 1999. I can’t say that I’ve been good at it for all those years, but they are what they are. At the same time, I have played with many other languages and platforms — C, Python, PHP, C#, REALbasic, FileMaker, Ruby, Objective C, Java. I’ve found that my experience with those other languages have been very beneficial to me when choosing a language and platform to follow at a new position, as well as being able to solidly argue why we use what we do, and what we do better than our competition because of it.
    There’s also the issue of job security. Those of us in the Perl community know quite well what the general consensus about our language is, especially when you aren’t flanking the west coast of the United States. As much as we cheer and evangelize and motivate other people to take a serious look at why Perl is a fast, modern development language, the world is moving further away from us. If you walk into a job a few years from now, and they see that you’ve been using Perl for 15 years and nothing else, they aren’t going to think that you’re a master of the language and you could learn anything else easily, as you allude to in your article. They’re going to see you as today’s world sees COBOL and RPG programmers — old hands who focused on one thing, and likely can’t handle modern concepts. Many COBOL and RPG programmers only get hired at positions that require maintenance of old COBOL and RPG programs. I’m not comfortable with that future.
    As developers, computer scientists, testers, and architects, our job, our reason for being here is to remain up to date and aware of what is happening in the world. If I programmed in Perl the same way I did ten years ago, I wouldn’t be hired right now. Becoming good at this language has been good to me, but I am not naive enough to think Perl is going to last forever. You must be aware of what Python, PHP, Ruby, and even PowerShell have to offer people, so you know why you continue to use this language, or whether you need to move on to another.
    It’s a value proposition.
    Distracting yourself for a week while you play with Ruby on Rails is not going to ruin your mastery, but it is going to help you realize why Catalyst and DBIx::Class kick so much ass.
    I’m done rambling.

  2. Web development Says:

    Good post!
    “Especially during an economic downturn, employers become more selective about who they hire.” – If you know several things then you are likely to stay in the company and manage db & code etc while the db expert OR the php expert gets fired. So it can work both ways 🙂

  3. ImpureScience Says:

    I like this post, and agree to a certain extent. I’m by nature a generalist but have found it valuable to get really good at something and make that expertise the linchpin of my career toolchest. However, as in love, there is always a downside to total commitment, and that is the sad fact that just as some relationships fail there’s a very good chance that the technology you’ve committed to will become tomorrow’s dinosaur. I’ve worked with and become relatively expert in quite a few operating systems, languages, and other related technologies that were subsequently relegated to the dustbin of history. A few examples: any Borland product, Gupta, Basic, Pascal, C (not C++), REXX, OS/2, Vax/VMS, IBM VisualAge, and so on. I don’t see this as wasted work, since the underlying ideas of which these technologies are concrete expressions are much more important in the bigger picture, but it does sort of blunt one’s ambition to get overly committed to any particular product or framework after a while.
    That being said, I have also had positive experiences with my last big commitment (Java) and domain-specific concentration (clinical research in academic environments) and find that my previous work is a big help in places that are still dealing with with legacy technologies.

  4. scawa Says:

    Your arguments are well thought out. And in some cases I will agree. One often looks to the specialist in a particular skill to fill a particular job or project.
    However, I have seen too many developers become locked into a specific skill set and then have their job outsourced, leaving them without a job because that skill set is no longer needed in the larger community.
    As an example, I had a work-out friend that was a real hot shot main-frame programmer. He had worked at a particular bank for 20 years and on the main frame for as long. I tried to get him to learn a new skill set, but he knew he had job security.
    His position was outsourced, before he had full retirement, and he was told to get a severance pay, he had to train his outsource replacement. He had only a specific job skill set and was un-hireable at other organizations.
    I program in several languages and learn more as my interests expand. My language of choice is Java and I like net based applications with extensive database use. That doesn’t mean to say that if a COBOL or RPG IV job comes along, I won’t take it.
    The problem with working with a narrow skillset is that if the only tool you have is a hammer, every problem looks like a nail.
    Stephen McConnell

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


%d bloggers like this: