Hey there,

Last week I had the pleasure of participating in one of LeadDev's StaffPlus panels (recording coming soon), which made me reflect a lot about my own career development. So today we'll take a break from software design to discuss one of the best things you can do to level up your career as a frontend engineer. I hope enjoy it!

In this week's issue, we'll talk about technical depth, technical breadth, the fundamentals of software architecture, and a model for drawing diagrams that actually make sense. Let's jump in.

CAREER

Go Deep, Then Go Broad

Where do you stand in the generalist vs specialist debate? Do you think it's more important to be an expert in a particular field, or is it better to be a jack of all trades?

I have the simplest answer to this question. Coincidentally, my answer is also one of my favorite early 2010s memes: why not both?

"That isn't really an answer, Maxi. It's just another question! (and a pretty convenient one.)"

Good observation, reader. I knew you wouldn't let me get away with that. I do have an actual answer though, and I promise to elaborate on it in just a minute. But before we get there, we need to talk about something else—pyramids.

The Pyramid of Knowledge

Imagine a pyramid. Or, if you prefer to work in two dimensions, imagine a triangle.

It needs to be a pretty big pyramid (or triangle) because it has to contain all of the knowledge in the universe about a particular domain. It could be a very broad domain—like engineering or accounting—or a very narrow one, like React development or Excel spreadsheet hacking. For today's discussion, we'll choose a domain somewhere in the middle: software development.

The top level of the pyramid contains all the stuff you know about software development. If you're a frontend engineer, at this level you'll find your knowledge of HTML, CSS, and JavaScript, as well as any other languages and frameworks you use on a regular basis. This might include React, Vue, Tailwind, Laravel, Git, or any other technology in your software engineering toolkit. Yes, you can put your Vim keybindings here as well.

The middle level has the stuff you know you don't know. All of the languages and frameworks that you sort of understand at a high level, but not completely, will go in here. This includes all the tools you might have heard of but never actually used.

In my own pyramid, the middle level includes technologies like Rust, SolidJS, and Qwik. I'd also put concepts such as load balancing, eventual consistency, and whatever "the edge" is in here. The criteria for placing something at this level is to have an understanding of what it is and what problems it solves, but without necessarily having to be an expert in it.

Finally, the bottom layer contains the stuff you don't know you don't know. This is where I'd personally put languages like Scala or Julia. Most knowledge about compilers, interpreters, and low-level programming also goes here in my case. And there's a bunch of other things I simply can't think of because, well, I just don't know about them. For example, what 99% of all AWS services do.

I learned about the pyramid of knowledge from the book Fundamentals of Software Architecture, which we'll discuss at the end of the newsletter. But… why are we talking about pyramids again?

The pyramid of knowledge is a great basis for our generalist vs specialist discussion. In particular, because we can use it to talk about technical depth and technical breadth.

Depth and Breadth

The top level of the pyramid represents your technical depth. This is the stuff you're good at. Your expertise. Your bread and butter. It's all the knowledge that you have that makes you a frontend engineer.

From the moment you begin your career, your focus is to increase your technical depth as much as possible, which you'll do via hands-on experience and training on advanced topics.

Maybe you'll learn about closures and higher-order functions in JavaScript, or about the performance impact of different CSS selectors, or perhaps you'll take an Advanced React course that'll teach out all of the framework's deepest secrets.

But once you reach a certain point in your career, this approach to learning new skills becomes less effective. The thing is, the top level of the pyramid can only grow so much. There's a limited number of things you can truly be an expert at, so the benefits you'll get by developing your technical depth alone will start to diminish over time.

At this point, I'd suggest you switch your focus to the middle level of the pyramid. Get a better understanding of more and different technologies, even if it's only at a high level. This is how you'll develop your technical breadth.

​

Shifting your focus to developing your technical breadth is quite a big step—it'll require you to get out of your comfort zone and start learning about things that aren't technically part of your job as a frontend engineer.

You might have to learn a bit about databases, backend development, GraphQL, messaging queues, product management, and maybe even some UX design principles. The goal is not to become an expert at any of these disciplines but to develop an understanding that will let you better articulate their benefits and tradeoffs.

Developing your technical breadth will feel uncomfortable at times, but it's one of the best ways to level up your frontend engineer career. Why? Here are some of the main reasons:

• It's the most effective way to operate at the Staff+ Level. If you decide to follow the Staff Engineer's Path, which typically involves taking on Tech Lead and Architect roles, your breadth of knowledge and experience becomes much more valuable than your deep technical skills. These roles are about making decisions from a higher level and understanding the needs of adjacent areas such as backend development and product design. A broad understanding of different types of technologies will be a driving factor in your performance as a staff frontend engineer.
• It's the way to break through the "frontend ceiling." Every once in a while, a discussion about whether frontend engineers are more valuable than backend engineers comes up on Twitter. The last occurrence was a few weeks ago, and as usual, people have all sorts of opinions about it. If you think being a frontend engineer can be a limiting factor in your career, developing your technical breadth will give you the best chance of success.
• It's the path to designing better software. Building software is all about solving problems and choosing the right set of tradeoffs. And the more ways you know how to solve a problem, the better the chances of making the right choices.

So, going back to my original question, is it better to be a generalist or a specialist? My answer is still the same; you should be both—only not at the same time.

Focus the first part of your career on developing your technical depth, but once you go deep enough, you should switch your focus to increasing your technical breadth. Become a specialist in whatever field makes you happy and productive, and be ready to switch gears and become a generalist later on.

There are exceptions to this rule, of course. Some developers find great success by becoming the expert in a particular area or technology, such as web performance, accessibility, or advanced CSS. If you're incredibly passionate about a particular field, then by all means continue to dive deeper into it. Just be cautious about letting your expertise limit your growth.

For most software engineers though, and particularly for frontend engineers, the benefits of becoming a subject matter expert and then increasing your breadth of knowledge cannot be understated. So go deep, and then go broad. It's the path to a more successful, enjoyable, and fulfilling career.

WATCH LIST

Visualizing software architecture with the C4 model

In this talk, Simon Brown tells us why most architecture diagrams out there aren't very good, why common standards such as UML are failing us, and how we can use the C4 model to help us overcome these challenges.

The C4 model gives us a way of visualizing software architecture by creating diagrams at four different levels of abstraction:

• System Context: the highest level of abstraction, which shows us the system as a whole, its users, and its dependencies.
• Containers: the different applications and data stores that make up the system. For instance, the containers of your system might include a web application, a mobile app, a database, and a REST API.
• Components: containers are made up of one or multiple components, each handling a different responsibility.
• Code: when we zoom all the way in, we'll find diagrams representing our code (classes, functions, UI elements, etc.) Here is where you might use UML class diagrams if you need them.

Simon has been teaching and speaking about C4 for well over a decade, and in the years since he introduced the model to the world, it has become one of the most popular ways of visualizing software architecture. You can read more about C4 on its website, but if you're looking for a quick and engaging overview of the model, I highly recommend watching Simon's talk.

​

ARCHITECTURE SNACKS

Links Worth Checking Out

BOOKSHELF

Fundamentals of Software Architecture

If you're looking for a comprehensive introduction to the world of software architecture, look no further than this amazing book by Mark Richards and Neal Ford.

Like most software architecture books, it doesn't include a lot of frontend-specific content. In fact, there's very little mention of the frontend at all. But don't let that discourage you from picking up a copy of this book. This is one of my most recommended reads for software engineers of all kinds.

The book has three parts. Parts 1 and 3 cover the foundational concepts, techniques, and soft skills necessary to become a successful software architect. You'll learn about architectural thinking, measuring architectural characteristics (e.g., scalability, maintainability, performance), and making architectural decisions.

These two parts of the book talk about architecture at a very general level, without focusing on any particular part of the stack. You'll find them very useful no matter which type of software engineer you are. As a frontend engineer myself, I found a ton of value in these two sections.

Part 2 is the longest in the book, and it covers in detail a number of different architectural styles, such as layered, event-driven, and microservices. Depending on your level of exposure to backend systems, you might find this part a bit more challenging to consume. But if you can handle the discomfort of not completely understanding all of the concepts discussed in this section, reading through it is a fantastic way to increase your technical depth.

​

That’s all for today, friends! Thank you for making it all the way to the end. If you enjoyed the newsletter, it would mean the world to me if you’d share it with your friends and coworkers. (And if you didn't enjoy it, why not share it with an enemy?)

Do you have any feedback for me? Feel free to reach out on Twitter or reply to this email directly. I read and appreciate all of your comments.

Did someone forward this to you? First of all, tell them how awesome they are, and then consider subscribing to the newsletter to get the next issue right in your inbox.

Have a great week 👋

– Maxi