I wrote a post for the Airtable engineering blog documenting the work done by myself and my team to upgrade Airtable’s MySQL fleet from 5.6 to 8.0. This effort was truly a saga, involving a team of 7+ engineers for multiple quarters. Read on to learn more.
A bit late, but I wanted to repost an Airtable engineering blog post I wrote with Caleb. This describes our engineering ethos of continually evolving our codebase, as illustrated by our migration to TypeScript. This was work mostly done before I arrived at Airtable, but I was lucky to have the opportunity to help tell the story.
Check it out on Medium:
2020 was a lot of terrible things, and one terrible thing we learned a lot about was wildfires. 2020 was the worst year for wildfires in California history, topping the previous worst-ever year in 2018. We saw the first ever gigafire (1 million acres burned) in California, and facing down one of the driest Januaries on record in 2021, it seems like year-round wildfires are the new reality.
Poor air quality is an insidious thing. You can’t always see it or smell it, and you might not feel sick. But, over time, these small particles build up in your body and have a detrimental effect on your lungs and heart. Population-level studies from polluted cities in China and India make it very clear: breathe a lot of fine particulate matter (PM2.5), die sooner.
So, air quality is a problem, but what can we do about it? The recommendation from the CDC and other health organizations is simple: stay inside. Wildfires and other major sources of air pollution like cars and factories are outside, so by staying inside, you lower your exposure to bad air. This makes sense, but when the skies are literally red because of suspended smoke particles, these basic measures may not be enough.
Continue reading →Sometimes I want to write a bit of code to automate a task. This can be anything, but a common pattern is a script that periodically wakes up, checks the state of the world, and performs an action. Think of Zapier, IFTTT, or Airtable Automations, but custom code.
The first time I encountered this problem, I solved it the way I would solve it professionally. I used AWS Lambda and the rest of the AWS ecosystem.
Continue reading →I’m pleased to announce the launch of equity.cool: the no-bullshit startup equity calculator.
This was inspired by conversations with friends who work at startups yet didn’t understand what their stock options were worth. Startups will intentionally try to obfuscate this number and advertise a rose-tinted picture of potential valuation.
I’ve worked at three startups at three different stages (Cloudera / Series D, Scale / Series B, Airtable / Series C), and have always maintained a personal spreadsheet for calculating the value of my option package. This has helped me compare job offers from startups at different stages, and also as a way of tracking the value of my equity over time. Although I’ve found it useful, when I’ve shared it with others it’s had limited success. It’s complicated to fill out, and there’s not much explanation for how to do so.
This motivated me to write equity.cool: a simple, no-bullshit startup equity calculator. It boils the required information down to the bare minimum, and spits out a single, big number: the total value of your options package.
I hope that the calculator is useful to others out there who are considering (or are currently!) working at a startup. You can read more about the calculator and how it works in the equity.cool FAQ, and of course, go to equity.cool and try it out!
When I previously used JavaScript, the grand debate was which JS utility library to use: jQuery vs. mootools vs. YUI vs. dojo. While I’m glad this tradition of grand debates has continued (Angular vs. React vs. Vue), the community has also quickly coalesced around the biggest improvement to JavaScript in the last decade: TypeScript.
In this post, I want to talk about my experience migrating an existing JavaScript codebase to TypeScript. But first, a quick digression on why I love TypeScript, and how TypeScript is the culmination of a number of great ideas in PL.
Continue reading →As the famous programmer Jean-Paul Sartre once put it, hell is other people’s code. This is what echoes through your head when you’re jolted awake at 2AM by PagerDuty, blaring about a Sev0 production outage. You trawl through the changelog to find the offending commit: a missing null check that results in an exception. You start rolling back the bad deploy, but as you sit there, illuminated by the glow of your laptop screen, you curse to yourself: how did a simple error like this make it all the way to production?
San Francisco to San Diego was my first multi-day tour, and overall I’m very happy with how it went. I’ve done plenty of overnight bike tours to Half Moon Bay or Samuel P. Taylor, and I carried basically the same kit on the multi-day tour.
Here’s a breakdown of what went well and what I might do differently on my next tour. I’m really eager to do the northern section of this route (Seattle or Portland to San Francisco), perhaps next year.
I spent about two weeks of my sabbatical riding from San Francisco to San Diego (Jul 31- Aug 15). I got in the habit of posting end-of-day recaps to Facebook and Strava as I went, which really helped me reflect on what happened. I’m reposting all of them here as a mega-post.
Total distance: 622.9 miles
Total climbing: 24436 feet
Total riding time: 55.85 hours
Sunsets on the beach: whenever possible
I’ve come full-circle. My very first websites circa-2005 were built with a CMS (Joomla or WordPress). I started messing with custom themes and plugins (which is how I really learned to code) then drank deeply of the semantic web koolaid and started hand-coded everything in XHTML, CSS, and PHP. I migrated to a static site generator seeking simplicity and reduced hosting costs, and now, umbrant.com is again powered by a full-fledged CMS: WordPress.