The Soft Side of Software

  Download PDF version of this article PDF

Breadth and Depth

We all wear many hats, but make sure you have one that fits well.

Kate Matsudaira


I often get asked for career advice. One of the things software engineers always want to know is if they should learn some new tool or language. In fact, I can't think of a performance review I have read for a software developer that didn't include something about growing their skills around a particular technology.

That is the nature of our work: it is constantly changing. You have to keep learning, or you will become obsolete.

But for your career, is it better to go wide and learn a lot of different things, or is it better to go deep and learn a few things really well?

Making the Case for Going Deep

Recently I was talking to another engineering leader about hiring and staffing. I asked which technologies he wanted people to know, and he responded that it didn't matter—a good software engineer can work on anything.

This has been the thinking at many large software companies in the past, and there are definitely merits to it—especially when you are hiring inexperienced candidates straight out of school. As I have worked longer in the industry, however, I have started changing my thinking.

I would argue that it is important to go deep in at least one area, and it is almost always better to hire people who have a solid depth of experience in the tools and technology they are using.

Why do you need to have deep knowledge?

Really good software engineers for a particular language or technology will exhibit qualities such as these:

• They are productive. They produce an amount of work that is above average, and they are able to get things done. This means they know how to use the tools of their trade well and aren't slowed down by not understanding something. They use their brainpower for harder problems, not learning how to do the basics.

• They make smart tradeoffs. They are able to understand the risks of their decisions. They have failed before and so can avoid mistakes. If there is a library or prebuilt code somewhere, they are probably aware of it—they may even have contributed to it or used it in past projects.

• They help others. Teammates go to them with questions because they have done this before and know how to do it right. This expertise makes them natural leaders or mentors.

• They hit their deadlines. Their estimates are almost always accurate. They know how long something should take them because they have experience working on similar projects.

• They are still growing personally and professionally. Since they are comfortable with the technology stack, they can use their time on learning skills in other areas such as leadership, communication, or even new technologies.

• They have a deep understanding. When engineers work with a particular technology for a long time, they learn the nooks and crannies of how it works—the good parts and the ugly parts. This can force them to think about the very constructs of how the technology was built. For example, discovering a bug in a foundational library teaches them to write better software. This depth also allows them to pick up other technologies faster.

When you hire engineers who have experience in a particular technology and can operate at this level, they are able to get up to speed quickly. They will have to learn the way your particular systems and software work, but they won't have to learn the tools and technology they were written in.

While there is definitely value in gaining that deep experience—and it should be part of your career plan—it is also important to have breadth.

Making the Case for Going Wide

When I look at my own career path, I can say it is my breadth that has helped me the most. As a developer, the fact that I understood operations, lower-level operating systems, and compilers helped me write better code. And as a manager, having experience with other disciplines helps me work with those people better.

For example, we have all written software tests, but when you work with really great testers and learn the way they think and approach problems, this helps you not only work better alongside them, but also write more robust code.

As a technology executive, you can't just understand the technology—you also have to understand the business. You have to focus on customers, think about product, and be able to understand the financial implications of your decisions. Often, you are managing people doing a job you have never done yourself—but you still need to be able to measure their impact and mentor them to success.

In these cases, it isn't enough to know just one technology well; in fact, if that is the case, you won't be successful. You have to have breadth and be able to think through other aspects of the problems you are solving, and you must have a broader understanding to work with people in different roles.

So Should You Go Wide or Deep?

I once had the privilege of having a mentoring session with a VP at one of the great software companies. I asked him about his background and what he felt got him to his position. He told me that he started his career as a software engineer and soon realized that being the best software engineer would be hard; software testing, on the other hand, was much less competitive, and a lot of people didn't have the passion for it that he did.

He changed his career path to pursue software testing and went on to write several books. He became one of the best in the world at testing and was asked to speak at conferences all over the world. The VP title and responsibility came later but was a natural progression.

His advice to me: pick something you can be the best in the world at. Specialize in it. Pursue it above everything else. Success will come along with it.

In many ways this is true. When you are truly exceptional at something, you build career capital, and you can trade that capital for bigger paychecks, more flexibility, or even fancy job titles.

When people ask me the question of where they should focus their time—should I keep learning one technology or spend time learning a new one?—I ask them that very question: What is the one thing you could be the best in the world at?

The answer might be going deep or going wide—the important thing is to spend your time on building the skills that will move you to where to you want to go.

Kate Matsudaira is an experienced technology leader. She worked in big companies such as Microsoft and Amazon and three successful startups (Decide acquired by eBay, Moz, and Delve Networks acquired by Limelight) before starting her own company, Popforms (https://popforms.com/), which was acquired by Safari Books. Having spent her early career as a software engineer, she is deeply technical and has done leading work on distributed systems, cloud computing, and mobile. She has experience managing entire product teams and research scientists, and has built her own profitable business. She is a published author, keynote speaker, and has been honored with awards such as Seattle's Top 40 under 40. She sits on the board of acmqueue and maintains a personal blog at katemats.com.

Copyright © 2017 held by owner/author. Publication rights licensed to ACM.

acmqueue

Originally published in Queue vol. 15, no. 4
Comment on this article in the ACM Digital Library





More related articles:

Abi Noda, Margaret-Anne Storey, Nicole Forsgren, Michaela Greiler - DevEx: What Actually Drives Productivity
Developer experience focuses on the lived experience of developers and the points of friction they encounter in their everyday work. In addition to improving productivity, DevEx drives business performance through increased efficiency, product quality, and employee retention. This paper provides a practical framework for understanding DevEx, and presents a measurement framework that combines feedback from developers with data about the engineering systems they interact with. These two frameworks provide leaders with clear, actionable insights into what to measure and where to focus in order to improve developer productivity.


Jenna Butler, Catherine Yeh - Walk a Mile in Their Shoes
Covid has changed how people work in many ways, but many of the outcomes have been paradoxical in nature. What works for one person may not work for the next (or even the same person the next day), and we have yet to figure out how to predict exactly what will work for everyone. As you saw in the composite personas described here, some people struggle with isolation and loneliness, have a hard time connecting socially with their teams, or find the time pressures of hybrid work with remote teams to be overwhelming. Others relish this newfound way of working, enjoying more time with family, greater flexibility to exercise during the day, a better work/life balance, and a stronger desire to contribute to the world.


Bridget Kromhout - Containers Will Not Fix Your Broken Culture (and Other Hard Truths)
We focus so often on technical anti-patterns, neglecting similar problems inside our social structures. Spoiler alert: the solutions to many difficulties that seem technical can be found by examining our interactions with others. Let’s talk about five things you’ll want to know when working with those pesky creatures known as humans.





© ACM, Inc. All Rights Reserved.