Welcome!
This is David Wetterau's blog. I live in New York City and work as a Software Engineer at Airtable. In my time at Airtable I've worked on new user-facing product features, new product verticals, and on all-sort-of-things AI. For many years, I worked at Dropbox primarily on the distributed systems that store and sync files and folders for millions of users.
Posts
-
Digitizing my handwritten journal entries
I have journaled every day since April 15th, 2018. Each of these entries is written by hand, and is one full page of a Large Moleskin “Classic Notebook”. With my handwriting size, this comes out to around 300 words that I write every day, by hand. In this post, I’ll explain the process that I’ve used to covert these handwritten entries into digitized text.
-
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.
- •
- 1
- 2