Specialization

This a chapter of the book Get a Better Developer Job. It’s best to start at the beginning.

This is the most important chapter in the entire book by a wide margin. Have you ever wondered how salaried programmers can make $200-300K/year or more? Or can start consulting from a beach in Thailand? You’re about to learn.

Maybe when you hear the word “specialized,” you get worried. Do you think “niche” is another word for pigeonholed? That you’ll be trapped?

In reality, the opposite is true: specialization is the path to freedom. Higher pay, more options. How? Authority. Authorities are trusted more and compensated better. And trust and compensation are the keys to freedom.

There are two ways to specialize: domain knowledge and technical expertise. Domain knowledge (which does not mean understanding DDD) stands out in many job ads. Most managers prefer to hire people with prior experience in their industry. Finance and health care jump out as two big ones. These are large, complex subjects and it takes time to get up to speed. I’ve done enterprise ecommerce, and there are a lot of 3rd party vendors and services you should be familiar with, not to mention nomenclature and how the data is structured. Staying within an industry gets you contacts, too, who can bring you on as they move up and around.¹ If you ever become a consultant, you will be surprised how decision makers at nontechnical companies do not care what technology you use and will switch from MS to Java (or vice versa) if there’s a good business case for it.

The best advice I’ve heard for determining if your domain is too niche is whether there’s a conference for it. That’s especially true for consulting, as a conference is a room full of potential customers (and yes, some competitors). You would be shocked at how narrow in scope conferences can be.

When I talk talk about a technical specialization, I don’t mean a specific language or framework. You can do that, if you’re passionate enough about the technology to want to evangelize it, do training, etc. But the tech industry has a broader split within technical specialization.

Let’s start with an analogy: things are made of stuff. Are you with me? Wait, don’t hit the back button! I’m going somewhere with this. What I mean more formally is that we make products using materials. Aluminum engine blocks. Rubber ducks. Glass houses. Both require engineers, but they are different specialties. The people who design the materials are material and chemical engineers, sometimes physicists. Lot of education, usually PhDs. The people who build the products using the materials are mechanical engineers, architects, etc. Less education is required because it’s less research-based. Software isn’t very different.

In our industry, we have performance engineers and application developers. Performance engineers build libraries, frameworks, and servers/daemons. Even operating systems and compilers.² These are the materials used by application developers, who build products for end users. Most large projects require both types of engineers, but managers frequently seek to hire one or the other, and it’s not always obvious.

Performance engineers work at a lower level. They’re never without their trusty profiler. They need to know things like time and space complexity of various algorithms and data structures, as well as platform internals. And “internals” might go beyond the garbage collection, into the network layers, OS, and hardware. It depends. Nowadays, when we hear performance we think of supporting billions of users, but look at what the embedded (or mobile) folks have to put up with to serve just one!

Application developers rarely have to know this stuff. Rod Johnson, creator of the Spring Framework, once said it made liberal use of reflection, but if he saw lots of reflection in application code he’d consider it a bad sign. A manager I spoke with recently admitted that software these days is more integration than development, and I was nodding like a drinking bird. So what do app developers need to know? Or be?

Well, they do need to know how to code. To maximize productivity, they need to write maintainable code. Human readable code. Of course, analysis and design are important, but if everyone can read your code and understand what it’s doing, they can improve it.

But most importantly, they need to be great communicators. Yes, code communicates to both machines and people, but an app developer is building something for an end user, and they have to get it right. They have to speak with users, project managers, and teammates and understand more nebulous concepts. It’s not that the performance engineer doesn’t have to, but they can communicate with a developer in a closer language.³ The number of times I’ve received requirements from a client, then had a conversation with him/her and determined we needed something very different, is legion.

The two developer types are on a continuum, and there’s a chance you could do either well. It’s just unlikely you could be excellent at both without a long career, poor work/life balance, or exceptional intelligence. If you haven’t made a conscious decision yet, now is the time. Here are some observations to guide you:

• If you want to do gaming, HFT, ad tech, OS, servers, or work for any company with heavy vertical or outrageous horizontal scaling problems, you have to know performance. Same with working at any prestigious tech company: Google, Facebook, Microsoft, Amazon, Yahoo, and a number of high-profile startups.
• Unfortunately, many companies hiring application developers interview them like they’re going to be doing performance engineering. Before applying, ask what you’re going to be doing and what the interview will cover. See if they match.
• The closer you are to the performance side, the longer and more lucrative your career as a coder. On Hacker News recently, there were comments about Google and FB paying people $200-300K or more, and that was Seattle, not the Bay area. A friend of mine got a job at Google in his 50s because of his lifelong interest in computer science.
• For application developers, the compensation ceiling is lower, but it’s a more direct path to management. Is that a better fit for you? What would you rather pursue: a CS Ph.D. or an MBA? Executive management can have compensation in the millions with fantastic perks, and if you’re primarily motivated by money, I recommend it.
• Application developers also have an easier time transitioning to independent consulting/freelancing, since so much of consulting is communicating with nontechnical people (that’s a huge part of sales). It leverages your domain/industry knowledge and the connections you’ve made, and your communication skills come into play when marketing (writing articles, giving talks, webinars, etc.).⁴

I’ve discussed with a number of developers and managers who agree with the patterns described. Have you’ve seen different?

Your Homework

Think about where you see yourself long term. What experience can you build on? Do you have domain knowledge and industry contacts to leverage? Is your computer science knowledge still fresh in your mind? Have you helped a variety of companies create technically challenging projects?

Help somebody's career:

Next chapter: The Truth About Side Projects