Three Unexpected Joys of Being a Specialist Front-End Developer

Three Unexpected Joys of Being a Specialist Front-End Developer

My mind was heavy with a conundrum early last year: How should I label my newly minted freelancer practice? Am I a front-end dev or a full-stack web dev?

I pride myself on being a jack of all trades. I love to jump into a new problem domain and pack enough domain / technical knowledge into my head to come out of the situation looking like a hero.

I historically called myself a full-stack developer who preferred working with the front-end side of things. Truth is, deep down I was afraid of closing off options that I knew all along I'm not passionate about – looking at you DevOps. I feared others would pigeonhole me for specializing 'too early' and miss out on the next trendy framework or paradigm shift.

Most of all, I thought specializing would make my day-to-day boring, I crave variety in my day-to-day life.

Fast forward today, not only am I a front-end developer, I am firmly in the front-of-the-front-end camp. I find more meaning in my work than ever before, and my overall career satisfaction is high.

Here are the three lessons I wish someone had told me a few years back:

T is not an I

Generalist vs specialist is not an all-or-nothing affair. I wish I had known about the idea of a T-shaped area of expertise earlier. In the T-shaped skillset graph of a 'generalizing specialist', there's a certain amount of depth in a wide range while specializing in only one or two topics.

This means there's nothing to stop me from spending a week learning a new back-end framework or machine learning technique. But my day-to-day is focused on one specialized area (Web Platform), acquiring the kind of skill improvement that only occurs with consistent, daily practice.

The only difference between a T-shaped skill graph and that of the generalist is an additive area of specialization, it does not take any existing ability away (outside of natural atrophy). Sure, my ML knowledge may become out of date, but I can still jump into a new problem and learn the latest tools like I always do.

It's giving up 'jack of all trades, and master of none' for 'jack of all trades, and master of the one thing you really care about'.

some cards on a table

Specialize to Learn More

If you told me a year ago 'you will spend much of the day thinking about HTML & CSS', I would've pictured a life with the sepia filter turned on. Where are the colors, joy, and variety that make life worth living?

Turns out, the complete opposite is true. What happened instead is both a narrowing of my programming stack learning and a widening of non-programming-related topics. Instead of focusing on all problems that can be solved via programming – an infinitely wide problem space –, I'm now focusing on the subset of problems best solved via the web platform. Instead of a stack full of programming books, my reading list this year includes books on CSS, web design, typography, writing, and general programming.

Taking a more concrete example, a year ago I may be looking at the MDN docs to learn about the font-variant descriptor. Today I have the bandwidth to do a much deeper dive into the graphic design principles that makes font-variant the correct tool for the job, such as how ligatures aid in readability and why small-caps are designed to live inline.

Learning how to use the latest toolset is much less useful than a deep understanding of the problems they solve.

Advancing the Field

Knotty, difficult, or novel problems are what move an industry forward. By definition, a surface-level understanding of a problem space cannot uncover its interesting edge cases or where its existing tools fall short.

Unless you are working on a new field where all problems are new and novel, specializing is the only way to move the field forward.

It seems very obvious to me now, but looking back, I underestimated the amount of satisfaction one gets from working in the bleeding edge of the space.

As an example, a relatively new CSS trick that belongs in my personal tome of 'CSS tricks to know by heart' is Heydon Pickering's Holy Albatross pattern. What I love about the trick is not its simplicity but how it's both a clever trick and a distillation of his style and approach to CSS – something that only comes after honing his craft for more than a decade.

Quick sidebar, if you enjoyed reading this article so far, please share it with others. If you really enjoyed it and don't want to miss the next one, you can sign up below to get weekly new posts in your inbox.

Taking the Leap

If you are on the fence wondering whether now is the right time to specialize, I want to encourage you to give specializing a shot. Say no to FOMO and pick a direction that you are interested in and dive in. You can still learn and practice other areas of your T-shape skillset, but you will also gain deep appreciation and skill mastery unavailable to generalists.

And if you enjoyed this article, you may also like You software engineering career in 5 degrees of DRYness, where I write about a pattern I see in developers' use and misuse of software engineer principles.

Show Comments