In a recent article, I argued that it is becoming even harder to be a credible full stack developer, one who is sufficiently up to date to contribute to every stage of developing a modern web- and/or mobile-based application. You’re not expected to build it all by yourself, obviously, but given enough time and with a little help from Stack Overflow, you could.

Such requirements were not unrealistic in the year 2000. In a typical LAMP-stack app (Linux, Apache, MySQL, Perl) you hand-coded most of your HTML and CSS. JavaScript was still optional and frameworks that kept all presentation concerns on the browser had yet to arrive. The backend created the views and besides a few indispensable modules (CGI, DB), standard Perl did the trick. 

True, a battle was raging between competing web "standards," with proprietary goodies like Explorer’s marquee tag and Netscape’s layers. But otherwise, the stack was reassuringly stable and manageable. The necessary tools on your belt didn’t weigh you down. And we just built simpler things back then, before the internet became indispensable. Today’s demands for scaling and security are much higher.

The Struggle for Survival

Browser compatibility is not the headache it once was, but with mobile added to the mix, it has become a different headache. For the developer, competing tools and languages battle it out in a Darwinian struggle for survival, especially in volatile ecosystems like JavaScript. The stack has not only grown in height but there are also many different competing stacks.

Just see what’s on the menu:

• For cloud, we have AWS, Google Cloud, and Azure to only name the biggest three US offerings.
• On the front end, we have React, Angular, Vue, and Flutter for mobile.
• For the back end, we have the C# and Java ecosystems. Concentrating on the latter we have good old Jakarta, Spring, and new contenders like Quarkus and Micronaut.
• On the JVM language front, we have Groovy, Scala, and Kotlin. TypeScript takes on JavaScript much in the same way.
• On the Java build tooling front, we have Maven and Gradle. Don’t get me started about building tooling in the JavaScript arena: it will be outdated by the time this post has passed moderation.

Don’t you envy those Cobol programmers of old? You rarely encounter the exact same stack when you switch companies or projects. You’re doomed to a lifetime of learning and junior proficiency when it comes to tooling.

The Go-To Helm Wizard

What is our reaction to this exploding variety? You would think the industry favors strong generalists: people with a reasonable, yet not expert, mastery over all areas that matter. It doesn’t. Instead, we get hyper-specialization.

Uwe Friedrichsen summarized it nicely in a recent blog series:

• Once you could be an operations expert.
• Then your area of expertise was reduced to virtualization expert.
• With the rise of containers, this was again reduced to, say, a Kubernetes expert.
• With the explosion of the Kubernetes ecosystem, the range was reduced again to being a Helm expert.

Being the go-to Helm expert can be a genuine day job in a large corporate environment. The same goes for other established tooling, like being an ORM/Hibernate specialist. Years ago, the definitive guide already ran to 800 pages. I have yet to meet anyone comfortable enough with all the intricacies of this ORM framework who doesn’t need recourse to some help — printed, personal, or online. Some tools have always been complicated, even when they claim to make your life easier. Nothing new there.

Friedrichsen is critical of hyper-specialization. It turns people into cogs in a machine, he argues. I think that’s too negative a point of view. The bigger the enterprise you work in, the more modest your individual contribution will be. To some extent that’s unavoidable. But it doesn’t mean such a contribution can’t still be vitally important.

To solve a particular challenge, you sometimes need to dive deep. In the Java enterprise arena, it’s a different challenge every week. But isn’t that also what makes the job fun and challenging? I don’t meet many hyper-specialists who are exclusively doing Hibernate or Helm forty hours a week. You’re more likely to find them among the traditional administration crowd, where their single product caters for many teams and thousands of employees. Oracle Database, SAP, and Siebel administration are genuine and lucrative career paths. 

Shallow Mastery Is Dangerous

Some in IT prefer being respected experts in a narrow field and don’t want to be generalists. Such an attitude would make others feel like cogs in a machine, but I have no value judgment about either. Deep and narrow knowledge is valuable, and a normal person can’t possibly command it from working memory to solve every day-to-day programming challenge. The sheer breadth of the ecosystem leaves you no choice but to become expert at just-in-time learning and web searches if you want to deliver working code within a reasonable time. You dig deep enough to solve an immediate problem, but no deeper.

But this shallow mastery is also dangerous, not to say unsatisfying. It is bound to yield sub-optimal solutions. The state of the art only advances when some single-minded people are willing to go deep. They are not generalists. Behind every innovation is a crazy amount of very specialist academic research.

Here’s my own drop in the ocean: I did my linguistics MA thesis on the nature of homorganic plosive clusters in Dutch and English compound nouns. In a nutshell: when you pronounce the word leg guard, the two g sounds blend into a single g, but one that lasts several milliseconds longer than the same g sound in "lagging," for example. Italian has the same effect also in non-compound nouns like notte. Dutch and German do not have this lengthening effect and I collected the evidence to prove it. Who cares, I imagine you thinking. Well, if you use Siri or Alexa and marvel at how a program can pick apart human speech, it is decades worth of hyper-specialist research like this that made it possible, done by folks who didn’t work at Apple or Google.