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. ...

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