Guillermo posted this recently: What you name your product matters more than people give it credit. It's your first and most universal UI to the world. Designing a good name requires multi-dimensional thinking and is full of edge cases, much like designing software. I first will give credit where credit is due: I spent the first few years thinking "vercel" was phonetically interchangable with "volcel" and therefore fairly irredeemable as a name, but I've since come around to the name a bit as being (and I do not mean this snarkily or negatively!) generically futuristic, like the name of an amoral corporation in a Philip K. Dick novel. A few folks ask every year where the name for Buttondown came from. The answer is unexciting: Its killer feature was Markdown support, so I was trying to find a useful way to play off of that. "Buttondown" evokes, at least for me, the scent and touch of a well-worn OCBD, and that kind of timeless bourgeois aesthetic was what I was going for with the general branding. It was, in retrospect, a good-but-not-great name with two flaws: It's a common term. Setting Google Alerts (et al) for "buttondown" meant a lot of menswear stuff and not a lot of email stuff. Because it's a common term, the .com was an expensive purchase (see Notes on buttondown.com for more on that). We will probably never change the name. It's hard for me to imagine the ROI on a total rebrand like that ever justifying its own cost, and I have a soft spot for it even after all of these years. But all of this is to say: I don't know of any projects that have failed or succeeded because of a name. I would just try to avoid any obvious issues, and follow Seth's advice from 2003.

(Shout out to Red Queen Podcast for introducing me to this book.) Becoming Trader Joe is, more than any other business book (certainly any other business memoir), a turpentine book. There is interesting philosophy and retrospective here — and Coloumbe, whether through earnestness or affectation, is a more literate and flippant narrator than your standard post-exit founder — but the meat and the merit of this is the absolute smorgasboard of anecdata and fun facts. Some notes: Trader Joe's counterpositioned themselves early on by making deals with suppliers that their larger competitors couldn't due to supply constraints: they bought, for instance, XL eggs at sub-market prices because the Krogers of the world were unable to purchase them as they wouldn't be able to distribute them to the entire corpus of stores in an areas. This let Trader Joe's both get favorable unit economics and counterposition ("we have this unique product that nobody else has!") Trader Joe's spent a lot of time figuring out how to compete and innovate in an ostensibly static market due to fair trade and other regulations: for instance, being unable to market California wines at a discount (due to price controls) but instead offering complementary wine bank access to accomplish the same thing. Lots and lots of pivoting. (Bullets used to be one of their best SKUs: standardized, value-dense, easily shippable.) Trader Joe's made the explicit decision to shift from "customer focus" to "buyer focus" in order to aggressively maximize deal flow. More than the sheer pleasure of reading — Coloumbe is a fun personality, and garnishes all of his stories with equal parts honesty and flippancy — this book strikes me as real. This is not a hagiography: it does not purport that all of Trader Joe's was a grand plan, but more of a series of strong base hits (with some misses as well) and a couple really great strategic shifts.

Consider a fan-out-ish model that you want to aggregate a bunch of: likes on a post, for instance. class Post(models.Model): created_at = models.DateTimeField() class Event(models.Model): post = models.ForeignKey(Post, on_delete=models.CASCADE) created_at = models.DateTimeField() Let's say we want to aggregate the number of likes on a post relative to the post's creation time (for instance, to visualize the growth of a post's popularity over time), yielding a list of tuples of the form [(minutes_since_post_creation, number_of_likes)]. def test_calculate_popularity_over_time(self): post = Post.objects.create(created_at=datetime.datetime(2020, 1, 1)) Event.objects.create(post=post, created_at=datetime.datetime(2020, 1, 1, 0, 1, 0)) Event.objects.create(post=post, created_at=datetime.datetime(2020, 1, 1, 0, 1, 0)) Event.objects.create(post=post, created_at=datetime.datetime(2020, 1, 1, 0, 1, 0)) Event.objects.create(post=post, created_at=datetime.datetime(2020, 1, 1, 0, 2, 0)) Event.objects.create(post=post, created_at=datetime.datetime(2020, 1, 1, 0, 3, 0)) Event.objects.create(post=post, created_at=datetime.datetime(2020, 1, 1, 0, 5, 0)) results = calculate_popularity_over_time(post) assert results == [ [1, 3], [2, 1], [3, 1], [4, 0], [5, 0], ] We might naively try to do this in-memory, by pulling everything out of the database and doing the math in Python, but that's going to be slow: import defaultdict def calculate_popularity_over_time(post): events = Event.objects.filter(post=post) minute_to_count = defaultdict(int) for event in events: minute_to_count[event.created_at.minute] += 1 return minute_to_count.items() This is an aggregation: databases are good at aggregations! Your first instinct might be to try to do this using ExtractMinute: from django.db.models.functions import ExtractMinute from django.db.models import F def calculate_popularity_over_time(post): events = Event.objects.filter(post=post).annotate( delta=F("created_at") - F("post__created_at") delta_in_minutes=ExtractMinute("delta") ) .order_by("delta_in_minutes") .values_list("delta_in_minutes") .annotate(count=Count("id")) But this has a bug. Can you spot it? Here's a hint: def test_calculate_popularity_over_time_different_hours(self): post = Post.objects.create(created_at=datetime.datetime(2020, 1, 1)) Event.objects.create(post=post, created_at=datetime.datetime(2020, 1, 1, 0, 1, 0)) Event.objects.create(post=post, created_at=datetime.datetime(2020, 1, 1, 1, 1, 0)) results = calculate_popularity_over_time(post) assert results == [ [1, 1], [61, 1], ] The problem is that ExtractMinute, well, extracts the minute, rather than truncates it. Extracting the minute from a duration of 1 hour, 30 minutes, and 5 seconds yields 30, not 90. Whatever are we to do? Well, we can take advantage of EPOCH to truncate the duration of a duration to its number of seconds, and then convert that to minutes: from django.db.models.functions import Extract from django.db.models import ExpressionWrapper, F class ExtractEpoch(Extract): lookup_name = "epoch" def calculate_popularity_over_time(post): events = Event.objects.filter(post=post).annotate( delta=F("created_at") - F("post__created_at") delta_in_minutes=ExpressionWrapper( ExtractEpoch(F("delta")) / 60, output_field=models.IntegerField() ), ) .order_by("delta_in_minutes") .values_list("delta_in_minutes") .annotate(count=Count("id")) I suspect there may be even more elegant and efficient ways to do this, but this satisfies a couple constraints: It delegates the heavy lifting to the database It doesn't require dropping down to raw SQL or registering intermediate tables It's fairly reusable and "Django-ish"

Hello, 2025! (As always, Death Cab remains the soundtrack by which you should read this.) Headlining this month was my annual review; everything else is flotsam. But, speaking of flotsam: A quick development note on the order attribute in CSS Notes on Linear and Fathom Why Buttondown has an 'alternatives' page Some thoughts on a nascent new newsletter project Letters to a young bartender A warning about hidden settings Only two pieces of media that I finished: Case Histories (meh) and Luck be a Landlord (much better) I have much to write; the backlog is longer than ever before, both literally and figuratively. Our water is out; our daughter is happy; we are keeping sane, and warm, and busy, and we are sleeping lightly but well.