Posts

Always leave something behind. If you find something interesting, leave a trace that you were there. This is a little thing that over time leads to a friendlier, more humane internet. Here are a few examples. Blog post that helped you Imagine you’re reading a blog post and you find it helpful. Or, you agree with it, but find one part of the argument lacking. Before moving on, leave a comment! ...

How do I “get up to speed” in a new codebase? Changing it. After trying almost every alternative— reading code, docs, tickets, metrics— I’ve found nothing that teaches a system faster than shipping a small change. Note: I wrote something similar to this a few years ago, which you can read here: Stop Studying, Start Building. That advice was for people learning to code; this is for starting on a new project, which is something you’ll do again and again a programmer. It’s worth trying to do well. ...

Approach caching with caution. In this post, I’d like to describe some important considerations that I think teams should consider before applying a caching solution. I’ve found: Caching is often applied too early. Caching can be a slippery slope. Caching is hard to do right. Often Applied Too Early Caching is often applied too early. It’s wise to try other alternatives first. Here’s an example: suppose we have an order-management system that fetches all the orders, and it’s performing slowly. Should we cache it? ...

I think many engineers would be better contributors if they started to think more about the customer impact of their work. Level One: Delivery Early in our careers, we’re looking for explicit directions, which we learn to deliver, and that is vital. Sophisticated checkout wizard? Complex domain model? I can do it! You learn to make it work and demonstrate that you can ship. Next Level: Thinking Like a Product Owner The next level is thinking like a product owner and asking: “Does this improve the customer experience?” ...

After reviewing a lot of pull requests, I’ve settled on a simple default: if my comments are all nitpicks, suggestions, questions, or non-blocking issues, I leave them and approve the PR at the same time. Here’s some detail on how it works. But first, two clarifying questions. Why Leave Comments, If Approving? Why leave comments if I’m approving? Comments show that someone has thought about the problem and the solution, and cares about what’s happening to the code. Occasionally, they offer a chance to learn or to surface misunderstandings, assumptions, or hidden risks. ...

When possible, I prefer to upgrade dependencies incrementally rather than making several version jumps. So, we try not to go from React 16 to 19. We go from 16 to 17, then to 18, and finally to 19. The Risks of Jumping Multiple Versions It’s very tempting to jump to the latest release. It feels like time travel; putting your application on the latest in the fewest number of steps. What’s not to like? ...

A policy I favor with dependency management: go forward. Going backward is an exception that we must plan to remedy. Example Consider a CVE in a dependency at version 5.0 (v5.0). We’re advised that v6.0 and v4.0 are safe. Which way should we go, forward or backward? We want to default to forward. Even if we’ve been on v4.0 before and know it is compatible. Even if we aren’t sure that v6.0 is “solid” or if it takes some code changes to implement. ...

If people can make catastrophic mistakes on your team, the process is broken. Real-World Example: Git Branch Protections An example is branch protections in a Git repository. These are rules that prevent engineers from deleting or altering history in shared branches, such as main, which on most teams would lead to a major problem. Engineers don’t intend to delete or alter main, but it can happen when rifling through terminal commands. We’re moving fast, and occasionally we press enter on the wrong command. As a contributor, I expect policies to catch me when I make this mistake. ...

Why do software teams push continuous deployment so strongly? One of the most important and least discussed reasons is engineer morale. Engineers Want to Build Engineers want to build. They’d much rather ship an experiment that proves or disproves a theory than discuss the theory. When you hire engineers who know how to ship, that’s what they want to be doing. Continuous deployment allows that itch to be scratched by eliminating barriers to building. That makes engineers happy. ...

Permanently forking a library is something I’ve observed on several teams. But, there are tradeoffs that aren’t always obvious. When to Fork: My Mental Model Here’s my mental model for evaluating when to fork: Dead project: this is the easy one. If the software is open-source and has an accommodating license, this can be a great solution to the “Build vs. Buy” question. Capable team that can maintain it: Got a team of pros who want to maintain a fork of a popular library for years? This might work. The library won’t merge or engage with your patch: You need the project to do X, but it won’t. After a reasonable effort, you might want to fork it. The Risks of Forking When you fork, until you pull from upstream or shut down your forked project, you own the code. You don’t have the maintainer(s) to help you, you don’t have new features from active contributors, and you don’t have enough eyeballs to make most bugs shallow. ...