Welcome!
This is David Wetterau's blog. I live in New York City and work as a Software Engineer at Cursor. I previously worked at Airtable on new user-facing product features, new product verticals, and on all-sorts-of AI things. For many years before that, I worked at Dropbox on the distributed systems that store and sync files and folders for millions of users.
Posts
-
Good code review tips
This is the third post in a series about code reviews. See the previous post to read about some ideas for who is responsible for what throughout the code review process. This post is a collection of practices that I’ve found and followed over the years as I’ve performed literally thousands of code reviews for my teammates.
-
Who fixes the bug?
This is the second post in a series about code reviews. Check out the first one to hear about why I think code reviews are so valuable to do. In this post, I want to explore the question of who ultimately is responsible for fixing the bugs and issues that a code review misses. We’ll start with two competing philosophies I’ve encountered on the question, and we’ll end with a healthy blend of both that I’ve found to be most productive.
-
Review more code
This post will probably be the first in a series on code reviews because I believe they’re greatly underappreciated. Every company I’ve worked at in my career has required that code is reviewed and approved by at least one other person before it is deployed to be used by the rest of the world. This is often something the company enforces for some compliance requirement, but I’ve also worked in really small environments where we still reviewed all of the code when we didn’t strictly have to. This system can feel overbearing and slow down teams, but there are plenty of benefits from doing them as well.
-
It’s just software, it can change
Early in my career I was working on a project that ran into some undesirable behavior with an upstream service we depended on. My teammate took me over to the team that owned that service and we had an impromptu chat about what the issue we were facing was and why the service had this (in our view) unfortunate behavior.
-
Send pulls not problems
I can’t take credit for the origin of this phrase, but I have used it many times. For anyone not familiar with Github’s terminology a “pull” request is (in non-technical terms) a proposed change to some code that a reviewer can choose to accept, request changes to, or reject entirely. A restating of this phrase would be something like: “don’t just complain about something, try to solve it”, but that’s not nearly as catchy.