Reviewing code is tricky. When I’m doing it, I’m trying to achieve a few things at once. In this post, I’d like to document the ways I try to add value via code reviews.

I recently calculated that I merge 0.8 pull requests every day into my team repo. “How to Deliver Code Every 0.8 Days” didn’t sing, so let’s say I merge about one PR every day, delivering one or more features to production. I like this velocity, and in this post, I’ll explain how you can achieve it yourself.

I’ve been a practitioner of Shawn Wang’s ‘Learn in Public’ for years. In this post, I’ll share a list of ways I’ve found to learn in public.

I recently hit a decade of professional programming. I’d like to take a moment here and reflect on what I’ve learned.

Here’s my annual professional review covering 2023.

When I was learning to program, I was fortunate to pair with very experienced engineers. One day while coding, I said: “I think we need to use Ruby’s map method, but I’m not sure how that works. Let me look it up.”

Later, my pair offered some feedback: “You can’t be looking up map. You need to know how all of Ruby’s Enumerable methods work.”

When I don’t feel like I’m making sufficient progress at work, I have a favorite technique: asking “What would finishing this today look like?”

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.