Why specialize as a software developer

Specialization for role advancement

Listening to my colleagues chat about a recent interviewee, I came to a realization about obtaining the ‘senior’ bit of ‘senior software engineer.’ Longevity in the domain or breadth of knowledge will never achieve a promotion because ‘senior’ means someone who is exceptionally well versed at [pick your language or framework]. Sure, a senior needs to have high-quality communication skills, but that won’t get them hired if they can’t demonstrate an esoteric level of knowledge in [pick your language or framework].

Ah well, guess that’s another reason I’m not likely ever to be a senior software developer no matter how many years I devote to it. I can write code in C#, Python, Golang and SQL, with frameworks like Angular/RxJS, React and Flask, but I’m not deeply skilled in any one of these core libraries or frameworks. Where others delve deep into a single stack, I want to compare/contrast between many stacks. So I can be a regular developer almost anywhere, but never a senior.

Specialization for “keeping up”

Baldur Bjarnason compares web development with other fields with frequent changes and concludes that web development doesn’t invest in its own industry. He lists three differences that reduce the pain of keeping up in other high-change domains:

  1. They have collective or institutional filters
  2. They specialize
  3. They conduct research, not “keeping up”

Baldur claims the industry’s bent towards “full-stack developers” is a cost-saving measure and turns us away from specialization. I think the full-stack moniker actually forces specialization by limiting developers to a single technology at each level of the stack. Where a front-end developer might become intimate with multiple front-end frameworks, a full-stack developer can’t afford to dabble outside their chosen technology. But maybe they’re not specialized because they’re required to use SQL, C#, and Angular? However, we probably do emphasize full-stack as a cost-saving measure due to limited developer (and financial) supply. If there was a glut of developers who were paid less, we’d see more applicants who only write one language in one context and more teams composed of specialists.

His insight into research methodology is invaluable. There are endless numbers of new technologies fighting for attention and I’ve been guilty of wasting time learning awesome new tech that’s not likely to be used in a corporate setting for years (or never). Setting clear thesis questions and limiting my exploration to answering those questions focuses my learning and ensures it’s more immediately relevant.

When Not To Specialize

If you’re an entrepreneurial polymath like me, you might find the advice to specialize makes you queasy. It can be disheartening to recognize that many in your current field have outpaced you by becoming specialists. But Tom Critchlow offers some hope in his wonderful article titled “Rejecting Specialization.”

💬

Many independent consultants are independent for a reason - we’re contrarian, we’re attracted to a myriad, varied array of work. We chase novelty and surprise - we’re often seeking an alternative path. And specialization doesn’t lend itself well to novelty and surprise.

Tom Critchlow