A design principle that’s crept into my programming could be summarized as:

“Absence of color is better than the wrong color.”

One of my favorite product hacks is asking: “What’s the why?”

Write a little bit of code, and you may come to an unsettling realization: there are multiple ways to do almost any programming task. How do we choose between several that work? I manage this uncertainty with a guideline: writing boring code. In this post, I’ll try to explain what boring means to me.

Something I’ve learned as an engineer: when presented with the option of working on a big project, or doing anything else, take the big project.

We spent the time writing tests, and yet, a bug survived. Should we just stop writing tests? No, but we should maybe write better tests, and think about them differently.

Have you ever seen a pull request that seems to completely explain itself? It’s a real artifact. I don’t know the project, yet I understand it. How can we get results like this on every pull request, from every developer on the team, every time?

Here’s some advice about programming, that also isn’t advice: “Don’t ask for advice; ask for a code review.” In this post, I’d like to explore what I think this means.

When it comes to controlling frontend presentation, developers often rely on booleans. However, this approach can be limiting. In this post, I’ll explore the drawbacks of using booleans and introduce a more versatile alternative: plain old strings with type safety.

I recently wrote about a debugging technique that I recommend: making a prediction. The idea is that before trying an experiment during a debugging session, we should stop and verbalize what we think is about to happen. I received a response that could be paraphrased as: “Isn’t that just debugging?” If only.

Absolute imports are an essential feature for me in any JavaScript application. In this post, I’ll explain what they are and why they’re great.