How I realized that being a versatile software engineer isn’t always a good thing

Photo credit: Christin Hume.

Early on in my career, I was happily building new features and diving into whatever different tech stack presented itself. I prided myself in the ability to jump in and get shit done. I was like someone who would never learn a foreign language to any level of basic fluency but could visit any country and ask where the bathroom is. Everyone liked working with me (as far as I could tell), and I was a versatile engineer who could help out on any team.

I identified very strongly as a generalist, someone who could take on a variety of tasks. I liked that I could figure out just enough pretty easily to get something done. When I thought of building technical depth, I imagined being a specialist like a hardcore database engineer who had worked on various database technologies for 20 to 30 years. I couldn’t commit to something like that. I’d rather be building and shipping features.

I was filler. Suddenly, being called a “versatile engineer” didn’t feel like a compliment anymore.

A few years in, I realized that the advice to stay a generalist for as long as possible wasn’t serving me that well. When teams were assembled, I was never the person that a team was built around—those were the specialists. These people were the givens because their unique skill set matched the project. Once these specialists were chosen, the rest of the team was filled in. I was filler. Suddenly, being called a “versatile engineer” didn’t feel like a compliment anymore.

I worked with my new manager to build depth in a few areas and systems, and I soon saw that building technical depth didn’t mean committing to something for the next 20 years at all. Once I became the most knowledgeable person in an area (in my specific instance, it was the notifications system and internal API design), people started consulting me on technical design decisions.

I started to have more opinions about our infrastructure and develop a deeper level of critical thinking and problem solving. When something didn’t make sense to me, I didn’t assume that it was that way because some all-knowing engineer had set it up just so. Instead, I tried to understand how it had become that way and suggested and made improvements.

It was the process of building depth and expertise that was invaluable. Working on something beyond the superficial level of just getting something to work is very different from understanding it fully after all.

Once you fully understand one complex engineering system, the next one becomes much easier to grasp.

When you learn one foreign language and all its conjugations and sentence formations, it becomes way easier to learn another one. Similarly, once you fully understand one complex engineering system, the next one becomes much easier to grasp. My T-shaped skill set was finally starting to grow a trunk rather than a stump. But building technical depth also made it easier to build depth elsewhere (hence the banyan tree metaphor).

Much more than a T-shape. 😂

I once interviewed someone who had participated in and won several hackathons. When I asked him what areas he thought he needed to learn more of to support a web application in production (beyond a weekend) with millions of users, he looked at me curiously and replied, “Well, maybe some backend infrastructure. But actually, now there’s AWS so you don’t even really need to know that much.”

Building technical depth also increases your understanding of what you don’t know in other areas and helps you develop empathy and become less insufferable to work with.