ISSUE 3Hey Reader, 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. CAREERGo Deep, Then Go BroadWhere 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 KnowledgeImagine 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 BreadthThe 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:
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 LISTVisualizing software architecture with the C4 modelIn 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:
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 SNACKSLinks Worth Checking OutBOOKSHELFFundamentals of Software ArchitectureIf 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.
|
113 Cherry St #92768, Seattle, WA 98104-2205 |
Get the latest articles, talks, case studies, and insights from the world of software design and architecture—tailored specifically to frontend engineers. Delivered right to your inbox every two weeks.
Read it on the website ISSUE 10 Hey Reader, I have some exciting news to share before we start—Frontend at Scale has officially reached 1,000 subscribers 🎉 This is absolutely incredible to me, and I cannot thank you enough for being part of this journey so far. Whether you’ve been reading my ramblings from the very beginning or you just joined us last week, I want you to know how much I appreciate you hanging out with me every two weeks. If you enjoy the newsletter, the absolutely best way to...
Read it on the website ISSUE 9 Hey Reader, I hope you had a fantastic week. Mine was great—I took some time off work to enjoy the beautiful California woods with my wife and kids, which was a much needed rest but also the reason there was no Frontend at Scale last weekend. I hope you didn't miss the newsletter too much 😊 Today I'm flying out to NYC for this year's React Summit US. I'm super excited to hang out with the nice folks from the React community and to give my talk, The Messy Middle,...
Read it on the website ISSUE 8 Hey Reader, Do you have plans for this upcoming Friday, October 27th, at 9:30am Pacific? Work, you said? I'm not entirely sure what that word means, but I hope you can make some time come chat about application design in Astro with Ben Holmes and me on my Twitch channel. This is the first of what I'm hoping will become a series of talks on frontend architecture and software design with different framework authors and experts, and I couldn't be more excited to...