Specialize In The New
Author’s note: This is part 4 of a series of essays I originally drafted about Opinions for your Tech Career. Part 1 is Learn in Public.
A fully expanded and revised version is available in The Coding Career Handbook!
You already know the value of a niche - you go up in market value the more specialized you are in anything. So what do you specialize in?
There are many schools of thought, including ones where you could be a generalist that doesn’t specialize in anything. I find one rule to be simplest and most effective above all: Specialize in the New.
Didn’t we just agree to avoid FOMO? Well yes, thats an important distinction - don’t specialize in everything new. Specializing means you have to say no to a lot of things. Just pick something new that fascinates you, and hopefully many others as well. Since you’re learning in public, you’ll know when you hit on a real nerve. Budget in the idea that you’ll fail a few times before you find Your Thing.
Then the other big objection: There are plenty of jobs/money/etc in (fill in the blank older technology) too! This is usually followed by some big numbers and anecdata. “My brother’s cousin’s roommate’s friend took this COBOL job and now he’s earning six figures on the beach in Tahiti!”
If that works for you, good. Here’s why I don’t do it. It is far easier to rise up the ranks quickly in a new space than in an old, crowded space. You know how people rant and rail against companies who hire based on years of experience? That could go away tomorrow and you’d still have clients/employers silently comparing you with others based on your years of experience. It’s human nature. But you know where it’s impossible for someone to have 5 years’ experience doing X? When X is less than 5 years old.
There’s a practical element to it as well - technologies accumulate a LOT of cruft over time. Best practices form, some of which are total BS, but that is stamped by early experts as The Right Way To Do Things because Reasons. Books are written, careers are made. If you choose to play on their turf, you’ll eventually need to read/deal with/overcome/win approval of all of that history. Even if you work twice as hard as the average developer you can only make up for all the context you missed half as slowly. You know where its possible to have read everything ever written about something? When it’s new.
The subheading to this is: Focus right next to where others are investing heavily. Joel Spolsky notes that demand for a product increases when the price of its complements decreases. “Complements” are an abstract idea so I will try to draw an example for you. If you brand yourself as a Firebase consultant and Google keeps adding and bugfixing Firebase functionality, they are in a very small way working for you (as you are also adding value to them). (Side note: this is why the developer relations job is a very special one for a midcareer dev - you are essentially a designated person showing off the investment of a company and team doing the real work in the background. As a focal point and an amplifier, you will get disproportionate credit.) As a developer (and not a startup) you don’t even really have to make the bank shot of figuring out the overlooked adjacencies next to an area of heavy investment; you can just make yourself all about that area directly and let the market tell you where gaps exist. What’s broadly true is that heavy investment usually leads to the cost or “price” of that thing decreasing, as the usual plan is larger scale at lower unit cost.
I have an economics background so if I lost you there, it’s my fault. But I really want to impress upon you that picking the right horse in this game of specializing for the new isn’t that hard because the market is going to be fairly obvious about it. Why more people don’t do it is because most people are busy being experts in other, older things. In this green field space, your “weakness” becomes a strength.
Plant your flag on fertile ground, and say, “this is what I do”. It will carry you far.
P.S. Clone open source apps using your technology; demonstrate how it is better and make fixes where it is worse. “react-router” was built by early adopters of React who simply missed the old router from Ember.