Welcome to Front End Center. My name’s Chris Landtiser, and this week we’re taking a look at the incredible spectrum of specialties and skill diversity in front-end web development.

Complexity in work is nothing new for the human condition. If your job consists of a small handful of simple things, like pushing a button every time you hear a beep, it’s because someone had to wrap their heads around a complex process and break it into parts before you started. Also, you should really find a new job.

Web development, like many facets of the technology industry, is both complex and fairly young. Unlike finance, law, or other established trades and practices, we haven’t really pinned down every title and specification. While a certain educational degree may qualify you for a dedicated title and type of work in a law firm, being a front-end developer is a very nebulous thing.

Over the last few weeks we’ve discussed JavaScript and Cascading Style Sheets at a very high level, and have seen how much can be learned and done within just two topics.

One of the challenges new web developers face is the conundrum of “how” to learn and employ their skills. On one hand, there is a LOT to learn, and it’s not all directly related. You can become a master of CSS without ever touching JavaScript. On the other, it’s pretty rare to find a position, especially in the front-end, where you aren’t responsible for multiple types of technology.

If you’re not already established as a JavaScript authority, you probably won’t get a comfy job handling only JavaScript every day. The old “Need experience to get experience” cliché holds true no matter what you do.

With that in mind, some degree of diversity is important at the start of your development career. But how to we grow from there? Setting aside the universal question of “What work do you ENJOY doing?”, we need to consider what sort of work environment you prefer doing that work in.

Focusing on incredible specialization means that you will be in demand for exactly what you do, and probably not much else. If you like working in larger teams that combine individual specialties for a final product, this might be the route for you! Complex corporate environments or dedicated “Software as a Service” can make great use of teams of specialists working in tandem. This sort of silo approach has been the default mode for many years in large companies, and is still in vogue in a lot of places.

Diversity, on the other hand, is always in demand for startups and smaller teams. Being able to handle work across multiple skill sets provides benefits from product cohesiveness to saving on additional hiring that may simply not be in the budget.

A popular piece of advice pertaining to specializing or diversifying is the “T Shaped” rule. If you mapped out your skills visually, you’ve got a reasonable amount of “horizontal” diversity and great “vertical” depth of specialization on one or two very specific topics.

This approach can be incredibly successful for a front-end developer. It encourages that early understanding of multiple technologies to form a career foundation. As you gain exposure to each topic, you can hand pick the types of work that you thoroughly enjoy and pursue those intensively.

I’ve focused my career on smaller teams and startups, as I enjoy environments that encourage collaboration and creativity over top-tier, separated specialties. Funnily enough, my current team is part of a much larger, international group that has more moving parts than I care to count. My direct work, though, is with only a couple other developers and our manager, and we refer to projects and requests as coming from external “clients”.

Even though we support a large amount of people with complex systems, our work method values agility and creativity. It combines our diverse skills to meet needs that would normally take many more specialists.

Having a small amount of developers with generalized front or back-end skill sets provides us a few benefits. We are incredibly agile as to what work we can take on. As business needs shift and priorities change, we can shuffle work internally with great ease. I don’t need to ask myself if a coworker who’s incredibly good with CSS remembers anything at all about JavaScript. Our manager can also breathe easy knowing that when he gets alerted to an immediate need, he doesn’t have to wait for “that one developer who knows that one technology” to finish everything else first.

With those experiences in mind, I’d like to propose an alternative to the T-shaped skillset: the ‘m-shape’.

While the T-shape is something that can form by passively adding related skills over a career, the idea of the m-shape is a little more deliberate. It’s a conscious effort to cross over skill sets and expand both breadth and depth in each.

It’s an idea that I think is right at home in front-end development in particular. Traditional silos like graphic design, development, and user experience can (and should!) be bridged! This doesn’t advocate for turning yourself into a workhorse that does everything for everyone in your career, though.

It’s almost impossible to apply one front-end skill in a void. A back-end database specialist can absolutely create, refine, and master a method of organization and data retrieval that ultimately returns the “same” result to the front-end. This entire process can unfold without even trying to understand CSS, and how it might be applied to that data later. It’s just not necessary!

The interweave of front-end skills makes that specialization more awkward, though. If a JavaScript specialist is told to style a certain element when a button is clicked, how do they approach that? Do they inline the relevant CSS styles? Do they need to arrange time with the team CSS specialist to co-author the solution?

Even if you only actively use on specialization on a regular basis, some depth of experience in parallel specialties will always be of use in front-end work. User experience informs design, which can be impacted by programmatic development, that is influenced by accessibility, and so on. The more silos you can connect in your skill set, the clearer the big ‘front-end’ picture becomes even as you work on just one piece.

There’s a certain joy to be had when you understand exactly how well a project is coming together, especially when you weren’t responsible for every minutia yourself. It’s much more fulfilling than putting your piece in place and accepting that “Oh look, it works.”

Til next week, thanks for tuning in! This has been Chris Landtiser, and Front End Center.