❤️ This post was originally published on my blog ❤️

In my short career, I've spent a bit of time thinking about:

• How do I be the best software engineer?
• What goes into an outstanding career?
• How can I be considered a valuable individual contributor?

Conversations I've had with peers and mentors quickly turn to the topic of specialization. If you read around online, you'll find a lot of arguments about whether it's better to be a specialist or a generalist in terms of the skills you build.

This is an especially notable topic when considering software engineering careers, because there's so much to learn, you can't possibly be the best at all of it.

Specialist vs Generalist

Cal Newport writes often that if you want something above-average from your career, you have to provide above-average value.

In his "So Good They Can't Ignore You", he puts it clearly:

If you want something that’s both rare and valuable, you need something rare and valuable to offer in return—this is Supply and Demand 101. It follows that if you want a great job, you need something of great value to offer in return.

The whole question of specializing vs generalizing for me is really a question of how I can offer the best value to my team. If I were superhuman, I would just become the best at all programming things and while I'm at it become the best at business things too. But that's not realistic, so many of us find ourselves wondering where best to focus our limited energy.

It seems to be common advice, at least in software, that specializing after building a foundation of knowledge is a good way to differentiate yourself. But what does it mean to specialize?

Saying that it's good to specialize isn't specific enough.

• If I specialize in Ruby, am I really specialized?
• What about Ruby on Rails?
• What about backend Ruby on Rails?

Even knowing that it's a good move to specialize still isn't enough information to make an actionable decision about what to get good at.

Keep Redefining What You Do

We already know that being the best at what you do is great.

I don't know about you, but becoming the world's best programmer seems like a daunting task for me. Naval talks a bit about how redefining what you do to make it easier to stand out:

If you really want to get paid in this world, you want to be number one at whatever you do. It can be niche—that’s the point. Become the best in the world at what you do. Keep redefining what you do until this is true.

Just becoming the best programmer is too hard. Becoming the best ruby programmer is hard, but not as hard. Becoming the best Ruby on Rails backend developer is a little easier. Becoming the best person at improving tests for Ruby on Rails apps is niche enough to be achievable.

It's a lot easier to be the best in a category of 10 than best in a category of 10,000.

Dual Mastery

I've found that a good way to continue refining what I do is to develop mastery in more than one thing. This is sort of specializing - Steph Ango, creator of Obsidian, calls it hybridizing:

The hybrid path means developing expertise in two or more distinct areas. Having several specialties allows you to see patterns that no one else can see, and make contributions that no one else would think of. The world needs more hybrid people.

My favorite flavor of Hybrid that Steph describes is the U-shaped hybrid, where one develops a wide base of skills with 2 specialties.

I'm still figuring out what this means for myself. I like to write backend code with Rails, but I'm also trying to develop my skills in infrastructure. I like to write code, but I also like to teach people how to write code through long-form tutorials. Fortunately, both of these paths are complimentary.

In the end, careers are long and these aren't one-way doors. I'm having fun experimenting and learning - I hope you are too.