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.1 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.

The technical side of specialization is… gosh, I want to write “insidious,” because it’s something we don’t often make conscious decisions about, or we make a series of small concessions that put us far from where we want to be. Typically, you just do what’s best for the boss or client, and that’s not always best for your career. And I’m not talking about what technology to use.2 I’m talking about something broader than that.

Let’s start with some context: 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.

Materials and mechanics are two vast disciplines, but somebody who is good at one could, with enough training, become good at the other. But if you think I’m going to make the connection between computer engineers and software developers, I’m actually going one step further.

I’ve struggled to get the taxonomy right, but I’m going with performance engineers and application developers. Performance engineers build libraries, frameworks, and servers.3 The materials. Their users are application developers, who build things for end users. Most large projects require both types of engineers, but managers frequently attempt to hire only the former.

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 millions of users, but look at what the embedded (or mobile) folks have to put up with to serve just one! They may call themselves hackers, but I think they may be honest to goodness computer scientists.

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 is communication 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 library developer doesn’t have to, but they can communicate with a developer in a closer language.4 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. Dig deep about what you’re going to be doing and what the interview will cover.
  • 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 in his 50s just got a job at Google 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.).5

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:

  1. I kid you not, that’s how most of the consultants I know achieved success. Executive friends are nice to have. []
  2. Although that’s a way to specialize, too. I have a friend who was an early adopter and amateur evangelist of a web framework and after a couple years was getting flown to Europe to speak at conferences. That’s pretty damn cool if you ask me. []
  3. A friend prefers the term infrastructure engineer, which is accurate most of the time. []
  4. You might think of design patterns as a developer language. []
  5. Yes, many people do performance consulting, but most of the time they’re working through the vendor or an established consultancy, not on their own. In general, performance people would rather spend time boosting their tech skills, not marketing. []