Happy New Year, friends 👋 And welcome to the last week of the year where it's still acceptable to wish someone a happy "new" year. It's been a while, huh? I hope you enjoyed your Holiday break as much as I did, and that you're kicking things off in 2025 with your batteries fully recharged.

Speaking of the new year, I have some very exciting things planned for Frontend at Scale in 2025 that I can't wait to tell you all about. I'm still working through some of the details, but I'll share more about them with you in the next couple of weeks.

This week, we have a super quick tutorial on how to read a book, a list of interesting links, and some of my favorite book recommendations for those of you who haven't given up on your New Year's resolution of "read more books" yet.

Let's dive in.

MAXI'S RAMBLINGS

How to Read a Book

At the risk of making it into the Naughty List this early in the year, I’m going to start things off by being a little selfish and talking about one of my favorite topics—books.

Now, I know books can be a bit of a polarizing subject to talk about. Some of you might love them, while others might think of them as an ancient form of knowledge transfer that only old people and academics still use.

If you’re in the second camp, I get it. I’m not going to try to convince you that reading books is a relaxing and enjoyable activity because, often, it’s not. But I do hope that today’s article and the recommendations I’ll share below inspire you to take a look at some of these books because I honestly think they’re worth your time.

So how do you go about reading a book? It’s actually quite simple. Here’s a quick tutorial that will teach you how to read a book in four easy steps:

• Step 1: Open the book.
• Step 2: Start reading it.
• Step 3: After exactly 2 minutes, realize that you’re no longer paying attention to what you’re reading because your mind has decided to wonder about some random topic. You know, things like what should you eat for dinner tonight, what is the meaning of life, or who would win in a fight between Pikachu and Sonic.
• Step 4: Go back to step #2 and repeat indefinitely.

I’m only half-joking here. As much as I enjoy books, I’ll be the first to admit that reading them (particularly technical books) can sometimes feel like a frustrating and never-ending struggle with your own head.

This is only made worse if you, like me, are a slow reader. I’m incredibly envious of people who can read a 300-page book in an afternoon. For me, reading a book of that size takes several days or even weeks—and that’s if I can convince my brain to stop thinking about how strong Pikachu’s Thunderbolt actually is.

But despite their drawbacks, I still think books are a fantastic way to learn and level up as a software engineer. Not because I think they’re superior to other formats (although there is a type of knowledge that is only available via books), but because they give us an opportunity to think and slow down.

Over the years, I learned to see the slow pace of books not as a bug, but as a feature. Yes, our mind tends to wonder about random things while we read a book, but it also wonders about how we can apply what we’re learning to our own work, which leads to understanding things at a deeper level. For me, these moments when we’re not actually reading but thinking about what we read are where the true value of books lies.

Getting to the point where we actually enjoy picking up a book and get to reap its benefits is not something that happens overnight, though. Here are a few tips to get you started:

Start small

If you’re trying to develop a reading habit, my top piece of advice is to start with a small goal (as small as “read 1 book”) and, optimally, with a short book.

Our brains love finishing things. So when it comes to feeling satisfied with your reading, finishing three 100-page books will be much more effective than reading half of a 600-page book. You might think that “satisfaction” is not a worthwhile metric to optimize for, but it might be just what you need to keep you going on your reading journey.

I have a few recommended short books in the lists below, but some of my favorites are A Philosophy of Software Design (~180 pages) and Tidy First? by Kent Beck (just under 100 pages).

Take notes (or don’t)

I highly recommend taking notes while reading a technical book, but I have to put a big fat asterisk here to encourage you—to implore you even—to stay away from overly complicated note-taking systems.

You probably know what I’m talking about: things like the Zettelkasten method or the “second brain” system. These are great for certain types of research, but for most of us mere mortals, these note-taking systems tend to just get in the way of the actual reading.

A few years ago, I was a big advocate of the Zettelkasten method for taking “smart” notes, which I used to keep track of all the books I read. I have a set of beautifully written and organized notes from this era that I remember feeling very proud of at the time. But my sophisticated system had a pretty serious consequence—I started reading less and less until I stopped reading almost completely. Even worse, I started avoiding some of the books I actually wanted to read because reading them meant taking detailed and organized notes which was such a massive chore.

So I quit and never looked back. Of course, I still take notes, but they’re much more “free-form” and easier to maintain.

I’ll write about my super-simple note-taking system in a separate post for those interested, but my high-level advice when it comes to taking notes is to remove as much friction as possible, use whatever tools you’re already using, and write notes in whatever format feels more comfortable to you. Don’t worry too much about organization and being able to find your notes in the future. AI can do that pretty well for us now, so just focus on capturing what seems important, and read on.

Make time

As I alluded to earlier, reading a book takes time, so it’s important that you reserve some of it for sitting down with a book and doing the actual reading. It doesn’t have to be a long time—even 15 minutes a day can help you read about a dozen books every year. As with most things, consistency and actually putting the time in your calendar is what matters most.

I do most of my reading every night 20 or 30 minutes before sleep, which… isn’t optimal for technical reading, honestly. Reading this late in the day often leaves my head “too active”, thinking about coupling or cohesion or whatever I just read about instead of going to sleep. But it’s the one time of the day when I can sit down with a book and read without distractions, so I make it work. If you can find an earlier time on your day for your focused reading, I’d recommend doing that instead.

Give up

Winners might never quit, but readers often do. If you’re in the middle of a book that you’re not enjoying, don’t feel bad about putting it down.

I’m sitting here giving this advice now, but this is something that took me a long time to be able to do. As a self-proclaimed completionist, I wouldn’t consider a book “read” until I finished 100% of it. This led me to push through some terrible books that I was definitely not enjoying just so I could put a checkmark on them.

I don’t know what changed (maybe I just got older?) but I now abandon books all the time—sometimes temporarily, sometimes forever. And I encourage you to do the same.

As a rule of thumb, if the first 30% of the book doesn’t capture my attention, I give up on it. I might skim through the rest to see if there are any nuggets worth reading in more detail, but I don’t force myself to complete it. There are plenty of books to read, and there’s absolutely no reason to read something you don’t enjoy.

Choosing What to Read

My number one piece of advice when it comes to choosing what to read is to choose something that is relevant and/or interesting to you right now. Be wary of lists that tell you the books you “must” read to be an effective engineer. You mustn’t read any books, only the ones you actually want to.

That said, I do have a few lists of books to recommend, and I hope you can draw some inspiration from them.

First off, here’s the list of my top 10 recommended books for frontend engineers that I put together last year. I think this list holds up pretty well, which is why I haven’t updated it this year. If you’re looking for a place to start, go check that one out first.

If you’re looking for budget-friendly options, I have a list of books you can read for absolutely FREE online on this LinkedIn post. You’ll also find a link to a pretty cool Github repository with hundreds of free technical books.

I didn’t read a lot of technical books in 2024, but I did read some very good ones. Here are some of my favorite reads of the past year:

• ​Head First Software Architecture — This book came out while I was working on the Fundamentals course, so the timing was perfect. I’ve always been a fan of O’Reilly’s Head First series, and this book is no exception.
• ​The Mythical Man-Month — The classic collection of essays by Fred Brooks. It’s incredible how many of the things he wrote about 50 years ago are still true of our industry today.
• ​The Art of Readable Code — Another relatively short read. It was published in 2012, so some of the code examples are a bit dated (yes, there’s some jQuery in there) but most of the principles in the book can be applied to modern frameworks.
• ​Kill it with Fire — A beautifully written book about modernizing legacy systems and future-proofing modern ones.

And finally, these are some of the books on my list for 2025:

• ​Semantic Software Design — This one has been on my shelf for a while and I’m very intrigued by its premise of being a practical guide for software architects.
• ​Software Architecture: The Hard Parts — The follow-up book to Fundamentals of Software Architecture, which is another of my all-time favorites.
• ​Learning Domain-Driven Design — A modern classic that promises to be a more gentle introduction to DDD than the original blue book.

I’m always looking to add new and interesting things to my reading list, so if you’ve made it this far (thank you!) and you have any books to recommend, I’d love to hear about them. Please send me any and all recommendations to [email protected] or just by replying to this email.

Happy reading!

ARCHITECTURE SNACKS

Links Worth Checking Out

1. Just before the holiday break, Schalk Venter from the Frontend Engineering & Design South Africa team invited me to ramble about talk very eloquently about one of my favorite topics—Understanding Complexity. This was a very fun experience and I really enjoyed our chat with Schalk about the role of software design in frontend development. I hope you give this one a watch!
2. Speaking of things I won't shut up about, Artem Zakirullin wrote about why cognitive load is what matters in good software design and what we can do to reduce it as much as possible.
3. Addy Osmani and Hassan Djirdeh teamed up with a group of ex-Twitter engineers to write a super detailed case study of how the Twitter Lite PWA came to be. This one is a long read, but very well worth your time.
4. Have you ever wondered what would happen if you put your favorite coding fonts head-to-head in a battle to find the one font to rule them all? Well, someone did. And the winner for me was... Roboto Mono?
5. Andreas Kutschmann wrote an in-depth guide on the Martin Fowler blog with some great tips for implementing a Design Token-Based UI Architecture. Another long read, but super useful for anyone looking to keep their design tokens organized.
6. We have talked about the importance of design docs before, but here's an alternative approach from Doug Turnbull that works just as well in certain cases: writing throwaway code.
7. Dmitry Bobryshev wrote a short overview of modern frontent architectures comparing the modular and featured-sliced approaches. If you're looking for a more detailed overview of these approaches, we talked about them in the Fundamentals course.
8. Dmitry Belyaev (yes, Dmitrys worldwide have been on a roll lately) wrote a detailed deep dive with more than you ever wanted to know about how to properly build a dropdown in React. I mean it's one dropdown Michael, how big can it be? Thousands of lines of code?

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?)

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.

I read and reply to all of your comments. Feel free to reach out on Twitter, LinkedIn, or reply to this email directly with any feedback or questions.

Have a great week 👋

– Maxi