Subscribe to access the entire course.
🌶️ tip: unsubscribe at any time.
Ah, that's a great question!
Frontend at Scale is a bi-weekly newsletter (as in, once every two weeks) that is all about software design and architecture for frontend engineers.
Subscribing to the newsletter is the best way to support my work and encourage me to keep making free resources like this one.
I probably don't need to say this, but I would never ever spam you—and you can unsubscribe with a single click at any time.
Already subscribed? Don't worry, you won't get double-subscribed. Nobody deserves to read my terrible jokes twice.
Module 1: Foundations
[00:03] Here is the question that every architect fears the most. What would you say you do here? And the reason that it’s so hard to answer this question is that there is no universal job description for what an architect is supposed to do. But in this video, we’re going to talk about some of the most common responsibilities that you can expect for someone in this role.
[00:23] Of course, we’re not talking about the traditional architects, the ones that sat on top of the ivory tower crafting perfectly designed architectures for months on end and then handing them off to the development team. That model of architecture doesn’t doesn’t work. That is the waterfall approach. And we know that it doesn’t work for building software. So that type of architecture doesn’t really exist anymore.
[00:46] Modern architects are embedded with the development team and they write code with the team, the review code with the team, and they iterate with the rest of the team as well. So if sitting on the ivory tower is not part of the responsibilities, what do they actually do?
[01:02] I think that there are three common trait that all architects have, no matter if they are frontend or traditional architects. The first one is that they are responsible for setting technical direction. I really like the way that Will Larsson describe this in the Staff Engineering book. And he says that this is because staff engineers and architects as well. They speak on behalf of their companies technologies.
[01:26] So you are responsible for creating a vision and a strategy and making sure the team is aligned on that technical vision and strategy as well. This also means that you will be making architectural decisions. These are decisions that we talked about in the in the previous video about architecture and design. And we’re also going to be writing and reviewing code.
[01:47] The code that you write may look different, but you still are going to probably going to write a lot of the code that you used to write as a developer. I write React code all the time. I still write CSS all of the time, and I think that’s important because you still want to have some level of depth on whatever is your expertise. You don’t want to be all breadth. And we’re going to talk a bit more about that in a couple of minutes.
[02:09] The second trait of modern architects is that they apply architectural thinking, which is a bit more than just sitting around and thinking about the architecture. I really like the way that Mark Richards described this in this great talk called Architectural Thinking, and he essentially breaks it down into three points. Understanding and analyzing tradeoffs, understanding business drivers and translating them into architectural requirements.
[02:31] So we’re going to talk about this to you in the next module and having a wide breadth of technical knowledge while still maintaining some technical depth. So you need both breadth and depth. This is what we were talking about earlier, and this comes from another concept that Mark Richard has, which is this pyramid of knowledge.
[02:51] Think of this pyramid as containing all of the knowledge that there is about software development. At the top level of the pyramid We have the stuff that, you know, the stuff that you are good at, your React expertise, your JavaScript knowledge. At the middle level, we have the stuff that we know that we don’t know. These are the things that we kind of know at a surface level where we’re definitely not an expert. And then at the bottom level, we have the stuff that we don’t know that we don’t know, like, like Kubernetes, for example, although we Googled what Kubernetes is. So maybe it sits around here for us now.
[03:28] So the top level of the pyramid represents your technical depth. This is, you know, your expertise, the things that you are an expert at, and the combination of the top two levels represents your technical breath. This is all of the things that you kind of understand at a high level, at a surface level at least.
[03:43] The reason that is important for architects to know about this stuff, and especially for frontend architects, is that making architectural decisions or analyzing, these tradeoffs will require you to know more about this level of the pyramid. The stuff that you know that you don’t know. So you need to expand your technical breadth and not just focus on becoming like the most expert in React or in view or whatever frame what you want to specialize on.
[04:15] You need good understanding of different technologies. It means going out of the comfort zone and figuring out, you know, how servers work, how how databases work, and other things that are typically outside of your responsibilities as frontend developers. But if you’re going to be upfront an architect, it’s important that you understand these so you can make decisions more, more confidently and make sure that you are analyzing the tradeoffs as correctly as possible.
[04:39] And finally, the last trait of modern architects is that they’re responsible for doing what Tanya Reilly calls “glue work”. If you’re not familiar with this concept, this comes from a fantastic article and talk by Tanya Reilly, in which she describes glue work as the invisible but very important work that we need to do so that all of the other work gets done. So this includes writing documentation or running meetings and doing some sort of mentorship and sponsorship.
[05:12] So as an architect, as a senior engineer, you have a responsibility also to grow your team around you, which means that one of your architectural concepts that you would learn, like the distinction between architecture and design that we talked earlier, you’re also responsible for sharing that knowledge with the rest of the team.
[05:25] There are two final things that I want to say about the frontend architects role. The first one is that you don’t need a title, even if that title doesn’t exist at your current company, which in a lot of companies they don’t have frontend architects as an actual thing. But you don’t need anyone’s permission to to think about the architecture, to care about the architecture. You might need some level of responsibility or authority to make architectural decisions or to set the technical direction for your team. But that can also come with other other titles like Tech Lead or Team Lead or lead developer and so on.
[06:02] And the last thing I want to say about the architects role is that architecture is not just the responsibility of an architect because it’s really everyone’s job. So even if you don’t care about having the architect role or about being in any position of authority on your team, you can still make things better for your team, easier to maintain and build a more robust system. But just caring about the architecture because it is at the end of the day already part of your job.