Thoughts on Rates of Change One of the first things I realized about working in codebases is that different parts of the codebase change at different rates. There are some files that are touched very frequently while others can go months, or even years, without being touched. This fascinated me, partly because it reminded me of my closet (why do I even still have those jean shorts?), and partly because people seemed to put such little thought into optimizing their projects to reflect this reality. The reason this matters is because every time you touch a piece of code, you have the opportunity to introduce a bug. It’s not like you’re intending to introduce a bug, but sometimes things happen when you’re working with code. Mistakes happen, but they can’t happen in that file if you don’t open the file. That’s why it’s important to separate out the parts of the code that will be touched frequently from the ones that won’t. When I first wrote ESLint, I organized the repository in a way that separated the high-touch code from the low-touch code. I reasoned that the ESLint core, the parts that actually do the linting, would probably change infrequently. On the other hand, rules were likely to be added, fixed, and updated very frequently. So I separated the core from the rules, creating separate directories for each. I also designed the core so that rules were loaded dynamically through configuration, meaning the core didn’t need to be touched just because a new rule was added. Here are some general guidelines for separating parts of your codebase based on the rates of change: Use the single responsibility principle. Robert C. Martin coined the term “single responsibility principle” to describe assigning specific responsibilities to specific pieces of code. He says, “Gather together the things that change for the same reasons. Separate those things that change for different reasons.” Practically speaking, this often means creating single-purpose classes in such a way that they can be composed together to create an application but can still be changed without affecting other classes. Keep code loosely coupled. Closely related to the single responsibility principle is the concept of loose coupling. Tight coupling means when class A changes that requires a change to class B. Unfortunately, tight coupling is difficult to identify in a code base and typically is found through the introduction of a bug where someone forgot to make the required change to another part of the code. Designing code in such a way that you don’t need to change anything other than the part you’re working on allows different code to change at different rates. Keep configuration out of code. Any data that isn’t dynamic (calculated or otherwise requiring logic) should be kept out of your code and in configuration or data files. For instance, if there’s an API URL that your code needs to hit, that shouldn’t be in the code. It should be read from a configuration file. Why? Because the URL might change in the future, and editing a configuration file is less likely to introduce a bug than editing a JavaScript, Rust, Java, or Go fil Keep unrelated code separate. As I described with ESLint, it’s important to keep code that changes at different rates separate from each other in your project. In its simplest form, this means creating separate directories for code that isn’t directly related. A more complicated form is to create separate packages for functionality that can be completely extracted and should be changed infrequently related to the application as a whole. Doing so reduces the attractiveness of making changes to code that shouldn’t be changed frequently. Key Takeaways
Stuff I've Enjoyed this Month🎬 How Canva saved millions in AWS S3 costs by KiKi's Bytes 📝Garbage collection and closures by Jake Archibald 🎬 Master VS Code's keyboard shortcuts in 13 minutes by Visual Studio Code 📚 Outlive by Peter Attia, Bill Gifford 🎬 React vs HTMX: Why we chose HTMX? by Kodaps Academy 📝Regexes Got Good: The History and Future of Regular Expressions in JavaScript by Steve Levithan What I'm Working On🏠 Real Estate: More bad news for my real estate investments this month. A couple years ago, I invested in several apartment building syndications. One of them was scheduled to refinance this year to return money to the investors, but that didn't happen. Interest rates are so high that refinancing would have led to bankruptcy. Instead, they sold a big part of the investment to a private equity group. While investors like me are technically still in the investment, the likelihood that I'll see any of my investment again is slim. I won't know for sure for another three years. It's a good reminder to diversify your investments. Follow my Instagram for real estate photos. 💻 ESLint: I created the official Markdown plugin to go along with the official JSON plugin. This is part of the language plugins work, allowing ESLint users to lint languages other than JavaScript...and there is more to come! |
A once-per-month newsletter discussing topics important to senior-level software engineers, with a particular focus on frontend technology and leadership.
Thoughts on Weaponizing Open Source When you think of open source software, you might think of it as a gift from someone to the world. They’ve written something of value, and instead of trying to make money off of it, they’ve posted it online for anyone to use (and potentially make money off of) for free. While many projects start that way (Linux, ESLint, etc.), there’s another way open source comes into being: as a weapon against a company’s competition. Android. Perhaps the best example of...
Thoughts on Node.js, Deno, and Bun If you started working in the tech industry after 2005, what’s going on now may seem like a shock. Large tech companies continue to lay people off despite record profits. Smaller tech companies are also laying people off, and in some cases, having “quiet layoffs,” where they find other ways to reduce headcount, including offering employees three months of salary to voluntarily leave the job. As a result, there are more software engineers looking for jobs in...
Thoughts on Node.js, Deno, and Bun For well over a decade, if you wanted to run JavaScript on the server, your only choice was Node.js. It has been battle-hardened by some of the most demanding companies in the world, many of whom paid employees to help maintain or contribute to the project. Then in 2018, Node.js creator Ryan Dahl announced Deno, a new server-side JavaScript runtime that was intended to fix a lot of the problems of Node.js. Fast forward to 2023, and Bun was released as...