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?