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.

It might be premature to write this review: I'm sure I'll play this game for another ten hours over the next month, and maybe by then (as is often the case with ascension-based roguelites) my understanding of the core game and mechanics will transform, and all of my forthcoming thoughts will be revealed as the meanderings of a novice.

This is a thing that I worry about more with negative reviews than positive ones, though: and I really liked Luck Be a Landlord, even if I found — find! — it a tiny bit wanting. It is in many ways a deckbuilder stripped down to the essence — build a deck, draw 25 cards in order — and your sole act of agency is to choose (or not choose) what cards/items to add to your deck.

Please do not mistake my elision here for disparagement: LbaL crushes this core gameplay loop. The combination of dopamine and analysis is second to none; it absolutely devoured me, even through the runs where I felt like I didn't lose so much as I didn't get great options in the first six hands. ^[1]

Where I find it lacking is depth once you understand the mechanics and synergies at play: the ascensions (at least the first ten, which took me around twenty runs to climb) are less about transforming the gameplay and more just increasing the incline; the universe of cards is pretty sharply divided into realms of Obviously Good and Obviously Bad, and the anti-capitalist intrigue is fun but doesn't actually contribute much to the gestalt of the game.

Seriously, though: if you like Slay the Spire, download and play this immediately. It won't be your favorite game, but you will have a great time with it, and there are many games that fail to hit that mark.

(You may be interested in 2023 as well, which was last year's annual review.)

Family

Haley and I welcomed our first child, a daughter named Lucy, on September 24th. She is perfect in ways both obvious and mystical. Our whole life is hers, now: this is even true of Telemachus, who proudly and rapidly assumed the title of big brother with characteristic gusto. ^[1]

I have more writing — which is to say more thinking, which is to say more doing — about what it means to be a parent, and how to be a good parent. We read the Oster books, we road-tested strollers; we were lucky enough to have a safe and relatively uncomplicated time at the hospital ^[2]; we slept for sixty minutes at a time, then two hours, then four, and now six. Everything is a lovely maelstrom; we have never been so lucky, to have found each other and to have the sibling and parents and extended family of friends and neighbors that we do.

Health

Ha-ha. I mean. I am going to grade myself both harshly and kindly here, which is to say that I'm in my worst shape since... 2018, maybe? I do not feel bad about this; I still try to eat fairly healthy and walk four miles a day ^[3] but there is not much else to counterbalance the "terrible sleep, much more delivery/takeaway, tremendous amounts of caffeine, no dedicated exercise time" melange in which I (just like every new parent) am adrift.

In the start of the new year, I'll be picking back up nSuns (which is quite literally exactly what I said last year before pivoting to a 5/3/1 program because nSuns was too taxing) and starting to do some jogging with hopes of improving my 5K time. We'll see! No plans (or hopes) to get into some hitherto-unseen level of fitness, just to shift back into a default state of discipline and posture now that the first wave of chaos has mostly passed and we have a bit more time and space to breathe.

Buttondown

Ending last year, I wrote:

The question that the industry trains us to ask is: what's next? I think that's obvious from a product perspective but a little less so from an organizational or business one: but my high-level goal for next year is to make a full-time hire, and all of the financial/existential commitments entailed therein.

It took me some time, but I'm ending 2024 with an answer to that question (see Why should a company?) and a full-time hire to boot.

Most of this year was spent in operations and development: I was a practitioner more than a manager, largely because I was interested in pushing Buttondown forward as much as I could before Lucy came. That was successful! Successful here meaning: Buttondown once again basically doubled in all of the metrics that matter, and it did so in a way that I felt honored my own ideals as an engineer, writer, and human.

Third South

Our goal with the first full year of Third South Capital was a diptych of existential questions:

1. Do we enjoy spending time and energy on this thesis, relative to other options?
2. Is this a financially viable thesis, relative to other options?

(And, yes, in that order.)

The answer to both questions proved to be a smashing yes, and in the waning weeks of this year we started to once again fire up our acquisitive flywheel. (Please reach out if you're ever interested in chatting about your company!)

jmduke.com

This was, legitimately, the first "real" year of writing in a long time for me. I think it was largely prompted by the increasing fracture of social networks and continued collapse of Twitter as a respectable, hospitable platform; I wanted to broadcast and no other better option remained than my own blog.

This year's biggest hits, by volume:

• Notes on buttondown.com
• Use weird tests to capture tacit knowledge
• Use Rails

(That being said, my favorite thing I wrote — in a crowded airport, on my way to MicroConf — was Two years as an independent technologist.)

For the first time in a long time, I've had people talk to me about my blog. The two most common remarks I receive are:

1. I love your blog specifically because it is so weird and idiosyncratic.
2. Why and how do you write so much? What are your goals?

I can say with some degree of smugness and honesty that the answer to the latter is the former.

Media

I don't exactly have a rich corpus of art to review from this year: the first nine months were spent being as heads-down as possible, and the last three were spent in a mode, as aforementioned, that offered little opportunity for consumption that wasn't audiobook-based.

That being said, the best things I experienced this year, in no order, were:

1. Austerlitz;
2. Possession (which I am not quite done with as I write this but is already locked in as one of my ten favorite books of all time);
3. Cromartie High School;
4. Le Samourai;
5. Legend of the Galactic Heroes
6. Mr. and Mrs. Smith;
7. Pokerogue;
8. Ripley;
9. Becoming Trader Joe (need to write this up, still!);
10. The Parallax View.

Coda

In retrospect, every cliche about parenthood is true; the one I found myself most surprised by was just how quickly and thoroughly a child seeps her way into every pore of your life, suffusing it with renewed texture and meaning and urgency. There is nothing I do now without Lucy by my side, either literally or figuratively.

In last year's coda, I wrote:

The median day of 2023 looked something like this: eight hours of sleep, a good workout, ten hours of exhausting intellectual work growing a business, some puttering around the house and tending the garden, two dog walks, an evening spent unwinding with my wife, an episode of anime with my brother. There are a lot of things I wish I could fit into that day: more time writing, more time exploring new technologies, more time playing video games, more time exploring Richmond. At the same time: I think I chose wisely.

And now, of course, I look back on that time of my life with not just a sense of detachment — again, to risk cliche every memory before your child is so aggressively The Before Times — but also a sense of irony that I could have ever felt like I didn't have enough time then. All I had was time!

And now, instead of time, I have a daughter for whom I would do anything. It is hard to fret about the things that fall away on the margins — a sourcing call that could have been interesting but certainly couldn't have been vital, a partnership talk that wouldn't work out anyway if the relevant details couldn't be hashed out over email, a great new restaurant with a wait measured in hours, a great new RPG that really hits its stride once you get past the first ten hours or so — when the alternative is this tiny little scientist of yours, bright and beckoning, whose every breath and burp and coo and cough is your charge and triumph.

What I am saying is this: it is hard to care quite as much about craft when fidelity has your eyebrows and your wife's nose — it is hard to care about scale when you have divinity asleep in your arms, sighing softly after three and a half ounces of milk.

(And I do care — and I do fret — and whenever I do too much of either, I peer into Lucy's bassinet and remember just how good we have it.)

Thank you

To my wife Haley, light of my life; to Lucy and Telly, precious and perfect; to everyone who sent us a note or meal or gift or hug for the first few weeks coming back from the hospital; to my grandparents, who I think about every time I see Lucy smile; to everyone who's patiently waiting on a response from me in Q4; to every customer who made it possible for me to step away from my job for two months and still afford Pampers; to you, dear reader, for getting this far.

(Order in the CSS rule sense, not the metaphysical sense.)

The time has come to begin exfiltrating some higher-traffic, higher-leverage parts of Buttondown's admin UI away from the autogenerated Django admin and into some more bespoke components.

Take, for instance, this rather grisly (but useful) inline admin table:

This contains useful information but is annoying to parse. It gets replaced with the following HTML, all still governed by Django and a wallop of Tailwind ^[1]:

It's a trivial thing, but lets me pull out a new toy that I learned from Mary a few weeks back: order, which lets you re-arrange the rendering order of elements in a flex container irrespective of their original order.

For instance, consider the following:

<div class="flex gap-1">
  <div class="order-2">world</div>
  <div class="order-1">hello</div>
</div>

This, as you might expect, renders as:

Where this gets really useful is composition with groups. Consider the following:

<div class="flex gap-1 w-[200px]">
  <div class="group flex-1 flex items-center">
    <div class="z-10 flex items-center justify-center size-6 bg-red-500"></div>
    <div class="w-full bg-gray-200 h-0.5"></div>
  </div>
  <div class="group flex-1 flex items-center">
    <div class="z-10 flex items-center justify-center size-6 bg-red-500"></div>
    <div class="w-full bg-gray-200 h-0.5"></div>
  </div>
  <div class="group flex-1 flex items-center">
    <div class="z-10 flex items-center justify-center size-6 bg-red-500"></div>
    <div class="w-full bg-gray-200 h-0.5"></div>
  </div>
</div>

This renders, unexcitingly, as:

But! Add a tiny sprinkle of group-last:

<div class="flex gap-1 w-[200px]">
  <div class="group flex-1 flex items-center">
    <div
      class="z-10 flex items-center justify-center size-6 bg-red-500 group-last:bg-blue-500"
    ></div>
    <div class="w-full bg-gray-200 h-0.5 group-last:order-first"></div>
  </div>
  <div class="group flex-1 flex items-center">
    <div
      class="z-10 flex items-center justify-center size-6 bg-red-500 group-last:bg-blue-500"
    ></div>
    <div class="w-full bg-gray-200 h-0.5 group-last:order-first"></div>
  </div>
  <div class="group flex-1 flex items-center">
    <div
      class="z-10 flex items-center justify-center size-6 bg-red-500 group-last:bg-blue-500"
    ></div>
    <div class="w-full bg-gray-200 h-0.5 group-last:order-first"></div>
  </div>
</div>

And you get:

Obviously, that is a lot of HTML to write for a very simple outcome. There are a bunch of ways you could reduce this. Why so much repetition? Why specify group-last for every node when you know it's going to be the last one?

Because in reality, the above HTML is actually, in Django, a pure and concise for loop:

<div class="flex gap-1 w-[200px]">
  {\% for item in items \%}
  <div class="group flex-1 flex items-center">
    <div
      class="z-10 flex items-center justify-center size-6 bg-red-500 group-last:bg-blue-500"
    ></div>
    <div class="w-full bg-gray-200 h-0.5 group-last:order-first"></div>
  </div>
  {\% endfor \%}
</div>

Which suddenly looks much more pleasant and maintainable than its conditionally-rendered alternative:

<div class="flex gap-1 w-[200px]">
  {\% for item in items \%}
  <div class="group flex-1 flex items-center">
    <div
      class="z-10 flex items-center justify-center size-6 {\% if forloop.last \%} bg-blue-500 {\% else \%} bg-red-500 {\% endif \%}"
    ></div>
    <div
      class="w-full bg-gray-200 h-0.5 {\% if forloop.last \%} order-first {\% endif \%}"
    ></div>
  </div>
  {\% endfor \%}
</div>

I invited nickd to join our Linear instance yesterday, which reminded me that I had a slew of notes I wanted to publish on our own experience of migrating from GitHub Issues to Linear, and some reflections on it as a product now that we've been using it for a few months.

• One useful lens for understanding a product's positioning and strategy is to look at what its primitives are — the experiences and states that stand alone (and hopefully offer value) without any exogenous or endogenous connections. ^[1] For Linear, the core primitives are issue and projects; you cannot, for instance, tie issues to initiatives, nor can you create a document that doesn't tie back to a project or issue. It does not exactly take oracular powers to assume that this is not going to be the case for much longer; it is easy and seductive to imagine a world where documents and writing of a more artificial, less project-based nature live in Linear, simply because that's the most pleasant place to write, read, and collate them.
• Regardless of Linear's success as a brand, it's very very clear that Linear's success as a product is simple: it is really, really good, in a way that is almost uninteresting. Linear offers very few novel features ^[2] and instead invested a lot of time, energy, and polish in... just getting everything correct, and making it work extremely extremely fast. (This is, to be clear, whatever the opposite of a backhanded compliment is.)
• [REDACTED BUTTONDOWN ENGINEER] commented that using Linear "felt so much better than using GitHub Issues that it made [them] want to actually spend time making sure their issues were up to date", and I echo that sentiment tenfold. There aren't a lot of bold new workflows or insights that using Linear has unlocked, but it has changed "backlog management" from one of my least favorite chores due to the lag of GitHub Issues into something that I genuinely look forward to doing because it feels suddenly tactile and cybernetic.
• Relatedly, what all of these nascent "Linear for X" tools seem to get wrong is that the specific design language and branding is downstream (or even orthogonal) to what makes Linear feel so good, which is its obsession with ergonomics. The hyper-designed table views and Things-style progress-indicator chart icons are nice, but they belie the obsession with performance. ^[3]

In case anyone's reading from the Linear team, my (meager!) wishlist is as follows:

1. Let me assign individual issues to initiatives
2. Docs as a first-party primitive
3. Let me mark certain views/issues as publicly visible (I know this one's niche!)

Some kind words from Chris Krycho on Buttondown's Alternatives page:

This is how I want all my tools to be. There is a ton of room in these markets for healthy and friendly competition — and no need at all for winner-take-all or monopolist attitudes.

First off — credit where it's due, I originally came across this genre of page on Memberful's site, and my reaction was pretty much the exact same as Chris's.

Two other points I'd make in favor of this page, or at least something spiritually akin to it:

1. All of Buttondown's product missteps ^[1] come from feedback from well-meaning, pleasant customers who deep-down are interested in a different product entirely. Being quite vocal about knowing who we're building for is a good reinforcement mechanism to make sure the customer feedback we get (both implicit and explicit) is coming from the right people, and not someone really enthusiastic about our brand + ethos but is really just looking for a CMS.
2. People have loud mouths and long memories, especially in long-term, infrastructural spaces like e-mail. My second-largest-customer by LTV was referred by someone who trialed and liked Buttondown and ended up going with a different product because we didn't have omni-channel; we have many customers who don't use us for their first company and then switch to us for their second company; my personal favorite anecdote is screenshotted below, where a customer who tried Buttondown shortly after launch (who I then referred to a different product that had better pricing at the time) came back six years later.

This applies more to companies as described in Befriending the Goon Squad, where your main goal is continued survival rather than winning a time-sensitive land-grab (or, if you're really early on in your product's life, it can be useful to yes-and every single customer request to random-walk your way to PMF — but neither of these options are things that I would personally do myself nor recommend to others.)

I've been on the hunt for a new way to dogfood Buttondown for the past month or so, and I've finally found it: Hypermodern Django.

At this point, all of my/our usages of Buttondown for Buttondown don't involve archives: we're using it headlessly, with RSS-to-email and APIs powering both this site's newsletter and the 'official' one. This is great, and I'm proud of the fact that we can even do that, but it means:

1. archives are turned off
2. the "general" analytics flow of everything archive-related is turned off

And this is a shame! I learn best about where the product needs evolution from usage; we've known abstractly that the archives are good-but-not-great for a while, and I suspect a huge part of that is because we're not using them.

So, the search (idle, errant) for a good newsletter concept began. I had the following criteria:

1. Something that didn't make more sense to be on the actual buttondown.com domain;
2. Something that wasn't expressly Buttondown-specific;
3. Something whose average reader might be a Buttondown user;
4. Something that wouldn't be expressly tiresome to maintain, either by me or by the Buttondown team.
5. Something that would be a legitimately good newsletter in its own right, not just a way to dogfood Buttondown.

And here we are, with Hypermodern Django. I've already been starting to write more about our Django usage (Improving Django's default pagination performance, MD5-based uniqueness constraints in Django, Postgres batch enqueuing in ten lines of Django) and this feels like a logical extension of that work in a niche that really needs it (in my experience, too much Django content is explicitly focused on novice-level usage, which of course is great but leaves a bit of a gap for more serious practitioners).

Anyway — that's the rationale. Please subscribe to Hypermodern Django and let me know what you think!

Three months ago, I wrote Bluesky et al, in which I walked through the various platforms vying for the dubious title of "Twitter's successor" and landed on Bluesky as being my favorite, perhaps less out of its ostensible inherent virtues and more out of the size of its alternatives' flaws.

Flash forward ninety days, and I feel as though I am a veritable Nostradamus ^[1] — Bluesky has exploded in growth, and much of its theoretical promise has been converted into reality. I struggle to point out a way in which it worse for my use cases than Twitter:

1. Thanks to what is, in retrospect, a genius UX innovation in "Starter Packs", the social graph that Twitter took a decade to meticulously build is now more or less extant in Bluesky. (There are folks missing — there's a lot of growth left to happen — but it's exited the awkward "first three people in a conference hall" phase.)
2. The app experience is performant, stable (relative to Twitter's), and rock-solid.
3. Engagement is higher than Twitter's (both for my personal account and for Buttondown's), and I am not subjected to the maelstrom of awful algorithmically-boosted chum.

More than anything, using Bluesky feels like playing WoW Classic or OSRS — it's in many ways consciously retrograde, and in much the same way that both of the "classic" editions of MMOs have since dwarfed their originators in popularity I would not be surprised if a similar dynamic plays out here: if the concept of a deterministic social graph has any enduring merit now that its sun has set, an app that doggedly clings to its users' nostalgia may end up more successful than one wishing to straddle both the past and the future.

Or perhaps Bluesky's business model — which to my knowledge is still somewhere between nascency and absence — won't work out, and it turns out the only enduring moats for this kind of business are either Panopticon or loss leader. I am not smart enough to guess, but I am grateful to have a social network I actually enjoy using, for as long as I'm lucky enough to have it.

Not a lot to share this month; it was a particularly busy time, between a mystery (and now solved, without fanfare or closure) cough and a dearth of time to write as I started to explore easing back into full-time work.

Still, some writing (and selfishly, I'm excited to end the year such that five essays is considered a "low" number for a month):

• Some thoughts on the industry: Shipping is capturing value, VC does not guarantee PMF, Klarna: nineteen years, twenty billion kroner
• Some press (and navelgazing): A good H1, Applied Cartography × Val Town
• Media notes on The MANIAC

Every straight white male is forced, character-creation-screen-style, to choose one overtly consumptive hobby that in some small part defines their twenties and – God willing — their enduring adulthood. Some choose sourdough; many choose barbecue; I chose mixology.

(A psychologist might suspect that this was in no small part due to being legally underage during my undergraduate years, and having a choice in extracurricular activity that precluded me from carrying a fake ID; a hagiographer might pinpoint the first cocktail I ever had (a Manhattan, mixed by the parents of my best friend in a hotel room during Parents' Weekend).)

Whatever the reason, I owe a not-insignificant amount of my blessed life to cocktails. The first-ever thing I sold on the internet was a cocktail app for iOS, planting the seed for later, more foolish attempts to sell things on the internet; I wowed and wooed my now-wife with a butterfly pea blossom-infused martini ^[1] which impressed her enough to go out with me again.

Maybe it's hindsight, but most cocktail writing on the internet is not particularly helpful. It's either Dave Arnold-style postmodernism ^[2], recipe analysis with little foundational insight that one would get from a couple years as a barback, or (particularly recently) recipe/bottle porn. What I wish I had was a list of now-obvious tips for keeping and running a home bar, and here is where I will keep them:

1. When mixing a conventional cocktail, start by pouring the most viscous ingredients first (syrups, liqueuers, etc.). Subsequent ingredients will help wash out the viscous ones from the jigger.
2. Two drops of saline in anything with citrus. (Four in an espresso martini.)
3. Freezer martinis (or other such drinks) are terrific. Be sure to put in around 1/8oz of water for each serving to dilute the drink in the same way that ice would.
4. Tovolo for ice cubes, unless you have the freezer space to justify making clear ice.
5. Always try a "perfect" version of something with more vermouth than you expect to be palatable.
6. Freezing citrus works really well — as does super juicing — but sometimes the point of the tea ceremony is the ceremony and not the tea itself.
7. It's absolutely fine to build old-fashioneds (and riffs thereof) in the glass.
8. Dry shake anything with protein.
9. Scaffas can be tricky to balance, and you often want to err on the sweeter, heavier side. (Bitters are particularly important.)
10. The point of a hobby is to be a dork.

At Stripe, we had two abstractions for branching logic in production: flags, which were meant to be explicitly temporal (temporarily split-testing traffic; rolling out a new feature or code path; exposing a specific path for a cohort of users during a closed beta) and gates, which were meant to be explicitly permanent (overriding a statement descriptor for a Thingish merchant; preserving historical functionality in a neglected API endpoint).

Gates were — are — considered a bit of a last resort, and pushing a new gate to production required a not-trivial amount of sign-off and acceptance from a number of teams, not just for the performance and maintainability burdens they created but for the sheer sign of defeat that they symbolized.

I say this as means of introduction to the anodyne concept of "hidden settings". Buttondown has hidden settings — who doesn't!: eighteen at the time of writing, down from twenty-two an hour prior. Every quarter I'll double-check the list and check if:

1. Anything can be 'mainlined' into a core setting available to everyone;
2. Anything can be 'unshipped' because nobody's actually using it.

Q4 2024's reaping: four completely unused settings, summarily deleted. None of these four settings felt, even at the time, like they were "worth it", and the anecdata bears that out:

1. The user who requested Setting A churned after one month (having never upgraded to a paid plan);
2. The user who requested Setting B churned after two months (having never upgraded to a paid plan);
3. The user who requested Setting C never finished onboarding;
4. The user who requested Setting D is an active and loyal user who never even used the hidden feature.

I am, on average, two years smarter and less foolish than I was when I introduced those four hidden settings, and most of the hidden settings look more like flags than gates at this point. ^[1] If it's a good idea to build, we build it properly (and triage it alongside the other forty-seven things we need to do properly); if it's not a good idea to build, it doesn't magically become more palatable by virtue of its obscurity.

I'd been meaning to jot down some thoughts on Fathom for a while, and did not have a particularly good reason to do so until the news broke that Paul Jarvis was selling his share of the company to Jack Ellis, the technical co-founder. ^[1]

Anyway, the two thoughts:

1. I think Fathom is a picture-perfect example of how to succeed in a niche that would otherwise be considered a fool's errand. Their biggest competitor is Google who is considered to own the industry and gives away the product for free, and almost entirely through counterpositioning and branding they are/were able to carve out a significant amount of revenue.
2. Paul is, to my knowledge, the only person who achieved significant success from branding and marketing themselves as a thought leader and then, rather than double down on the onanistic meta-spiral of "here's how you become an author/creator", completely pivoted to SaaS and left the zeitgeist behind. Incredible!

The market for Google Analytics alternatives is crowded in 2024 compared to 2020; I'm still very happy that Buttondown's using Fathom. (Though, Jack and Paul, please — funnel support would be really nice.)

And she was crying because she didn't believe in Jesus or dog heaven and no one was ever going to lie in bed with her on a Sunday morning and read the papers or rub her back and say, "Is there anything I can do for you?" And because there was no happiness, only emptiness. And because she wanted to be sixteen years old with long shiny hair (which she'd never had), and she wanted to be looking anxiously out of an upstairs window and hear her mother downstairs shouting, "He's here," and then she would run lightly down the stairs and climb into the car where at the wheel would be her good-looking boyfriend and they would drive away and have warm, blurry sex somewhere and then he would bring her back home and her family would be waiting. Victor would acknowledge her with a gruff paternal nod as she came in the door, contrary teenage Julia would ignore her while willowy first-year student Sylvia would smile in a superior manner. Somewhere, in the guest bedroom perhaps, the vague unformed shape of a five-year old Annabelle could be found sleeping. And Rosemary, her mother, would ask her, in a womanly, conspiratorial way, if she'd had a nice time and then would offer her hot milk and honey (which she was sure she had never done in real life) and perhaps before she dropped into the sweet untroubled sleep of a pretty sixteen-year-old, Amelia would look in on Olivia, eight years old and safely asleep in her own bed.

Kate Atkinson is so truly world-class at writing sweet, flawed people who want and deserve and do not get happy endings — Life after Life was one of my favorite books of 2021, and Transcription (having chosen to read it purely out of Atkinson Mania) was, despite some plotting missteps, equally fun and rich. And much of that same brilliance is on display here: her ability to move through dark humor, sweet innocence, and cutting wit often in the same paragraph is channeled through a host of thorough and well-crafted characters who often are not afforded agency or interiority but lesser authors of the genre.

Where I think she stumbles a bit here is in marrying that terrific joie de vivre and personality work to a plot that demands a certain level of convention and satisfaction. Crime fiction (fair play or no) is a bit of a contract with the reader: if a book opens with three disparate murders, you are meant to believe that the book will end with the resolution of those three murders, and also a satisfactory intertwining of the three — and indeed the pleasure of the genre is you weighing every single new scrap of information, every tell and tossed-off detail, and seeing if it fits into the whole or sways your analysis. Atkinson knows this — she ends the book (no spoilers, at least in any meaningful sense!) with resolutions to all three murders and, if you squint, a rough lattice that conjoins the triptych.

But I am a snob with these things, having been spoiled by Christie and her uncanny mastery of puzzle-box craftsmanship; and perhaps it is an unfair standard to judge any work that attempts to elevate the murder mystery into the realms of literary fiction by the standards of Christie, but nonetheless that is the standard, and Atkinson finds wanting. Jackson Brodie is no Hercule Poirot (perhaps this is one of those situations where the cliche was less obvious in 2004, but "British cop with a gruff exterior but sweet heart and a sad past" does not exactly Do It For Me), and the revelations in the third act meant to be shocking were easily sniffed out in the first act, and I was left with a sense of — not the satisfaction that great mystery novels can provide, nor the metatextual refutation of such satisfaction offered by works like The Name of the Rose — fondness, for the people whom I got to spend some time with, though not exactly an aching to spend any more with them.

(Also, as mentioned in The Diamond Age: it is poor analysis, but nonetheless relevant to say that books about dead daughters now take on a deep and newly-textured pallor in a way that I could have not imagined a year ago.)

I tend to ignore the entire genre of what we now refer to as BNPL businesses — Affirm, Afterpay (RIP), Klarna, et al — not for any particular sin I feel that they are committing, but because they in my mind are much less interesting companies with less volatile upside than the Stripes and Squares and Adyens of the world.

It's tempting to think of these companies as a successor cohort to Wachovia and other since-departed financial firms — organizations that survive and persist in a commodity landscape due to operational rigor and process power and existing momentum more than for any other ineffable asset, a sort of fintech Yes, Dear. ^[1]

It is in that deeply cynical light that I listened to a pretty delightful interview with Klarna's CEO, Sebastian Siemiatkowski. Most CEO interviews are in one of two buckets: "this person is abusing stimulants and has a lot of points to convey" or "this person's PR team has coached them into complete banality". Conversely, Sebastian here has a lot to share: I thought this was an uncommonly honest and insightful interview, and I'm not sure I'm used to a CEO of an active company admitting so many mistakes in such little time. Some notes:

• Klarna, like many technology firms that quietly grew in Europe before exploding onto the US scene due to one particularly wide-eyed VC firm, has been around for a long time, and history has its own innate advantages.
• Obviously the full story is in the process of being told (as I write this, Klarna is still not particularly close to profitability) but Sebastian delivers the story of Klarna's pivot from largely back-office infrastructure to trying to compete in full-stack payments to pivoting to fighting the BNPL wars to doubling down on consumer-facing surfaces in a way that is much more useful than other corporate bildungsromans. Nineteen years is a long time for a software company in a blood-soaked industry to stick around.
• The insight that Klarna can outcompete legacy providers because of their ability to ingest and surface SKU-level information is a great one, and an example I think I will return to often. Even if it's a little post-hoc, I think taking a look at the downsides of deeply-integrated systems and understanding how you can exploit their coordination problems is... interesting.
• I get klarna.com (and that entire genre of wrapper-browser) now! Insanely clever. ^[2]
• Life is long, and relationships change, and organizations you consider rivals may be your trusted integration partner in three years time. (And five years after that, they might be trying to put you out of business.)

Buttondown was kindly featured in H1 Gallery last week, and Ryan asked me to opine a bit on how we arrived at our current iteration, which is the anodyne yet pointed Email for you. Yes, you.

Historically, we've called Buttondown a 'newsletter tool' — the h1 before this was 'The best way to start and grow your newsletter.' This was really nice and effective, but I talked with a number of folks who felt a little turned off by that word "newsletter", as if it felt amateurish or insufficiently "haha business" (for lack of a better term) for their use case.

So I started toying around with replacing "newsletter" with "email" as the proper noun that we'd rally around (and email has its own baggage, to be clear — there's a handful of people who sign up thinking that we're, like, a Proton Mail alternative.) And the more I liked "email", the more I hated "email " — email automation, email marketing, email campaigns all felt very corporate and stodgy in a way that betrayed the unique voice I think most of our marketing copy has. Eventually I landed on "email for people like you", which I liked but lacked... a certain punch, if you know what I mean.

Finally, I was batting around ideas and landed on the current two-sentence structure, which I think accomplishes a handful of things:

1. Tells the user, frankly, nothing about our product or positioning besides "email" (and therefore invites them to learn more)

2. Immediately gives us a certain voice and friendliness that is, uh, missing from the Constant Contacts of the world.

Two other notes:

1. This current iteration — much like the current iteration of the site, brand, and vibe of Buttondown, comes just as much from the inimitable nickd as it does from me. ^[1] One of the virtues of Buttondown being around this long and having the user base that it does is that when I work with people, they already get what we're going for.
2. I've said this a couple times already, but — the best part about running a software business is the freedom to have fun with things, and part of that freedom is recklessly changing your H1 as often as you like. We do seasonal H1s ("Email software that's all trick, no treat"; "New year; new you; newsletter.") — even if they tank conversion for a few days, it's fun.

This great essay from Sean Goedecke went viral two weeks ago, drawing fury and fervor alike for a Moral Mazes-esque analysis of how engineers at large companies should think about shipping:

Shipping is a social construct within a company. Concretely, that means that a project is shipped when the important people at your company believe it is shipped.

This essay reminded me of Zach Holman's on 'Double Shipping' from 2018, in which he argues the same point — shipping is not an actual concrete event so much as a social construct by which we proselytize:

One of the things we did all the time at early GitHub was a two-step ship: basically, ship a big launch, but days or weeks afterwards, ship a smaller, add-on feature. In the second launch post, you can refer back to the initial bigger post and you get twice the bang for the buck.

Three useful things to internalize as early as possible in your career:

1. The act of writing and deploying code is more akin to potential energy than kinetic energy.
2. The platonic ideal of software development is a world in which changes and improvements are instantly and comprehensively understood by all stakeholders; the delta between this ideal and reality is much larger and more pernicious and more valuable than software itself.
3. Nobody has even a fraction as much knowledge or context or even baseline awareness of what you're doing as you do.

It's very easy — and comfortable! — to be cynical about this kind of stuff. Certainly there are organizations notorious for prioritizing shipping in a pluperfect sense — Google, for instance, and their promo-doc-driven culture. Certainly there are organizations that wither and die because their engineering culture is insular and insufficiently collaborative. Certainly there are great engineers who build great things and are washed out of the company because they "didn't politic enough". Running big technical organizations is an unsolved problem; there are few strictly correct answers.

Here is a slightly different and more useful framing: when you are writing code, start from the why — who cares about this thing, why do they care, and what is their success criteria? That person might be you (or future engineers on your team); it might be a customer (or one who is secretly planning on churning next month anyway); it might be a VP (who green-lit the project largely as a reason to get a couple extra heads). Willful ignorance of the answer "what happens, what really happens if this thing never hits production?" (or, conversely, "what happens if this thing hits production and is never used?") is the path to being a capable "programmer" with no leverage or cultural capital.

(Put another way: Your job is to produce value, and code is Work in Progress and not the value itself.)