Two companies that I started following (with no small amount of envy) back in 2021:

• Hype (fka Pico) sold to an MMA-themed holdco earlier this year. Raised a $4.5m seed from Stripe and Bloomberg Beta and a $10m Series A; crossed the finish line at $200K ARR after eight years.
• Stir (which raised $16M from a16z at a $100M valuation) informally shuttered some time last year. As far as I can tell, they never GA'd a product.

These two examples are arbitrary: it only takes a few years for any venture capital-subsidized gold rush to be littered with thesis-driven investment memos for companies that never found product-market fit, in no small part because they were never forced to.

As I wrote in Befriending the Goon Squad:

This is an important message for independent developers to internalize: especially in crowded markets, survival, not victory, is the success condition.

(Lest this sound too censorious: I think venture capital is a useful financial instrument. I think there are many really ambitious, gnarly problems that simply require a lot of capital to solve! But it requires a certain level of luck, grit, and patience to land your tenterhooks in a competitive niche, and venture capital provides none of those things to founders who do not already have it.)

Hello! Lots of writing in October (what early parenthood takes away in terms of deep flow, it gives back in terms of twenty-minute pockets of time and thought):

• On the content front, I wrote about Monster Sanctuary (a delightful JRPG), The Anderson Tapes (a solid late-period Sean Connery heist), Trust (a rare postmodern novel that I disliked), Wolfs (meh, even with Pitt & Clooney to keep the thing afloat), and Slow Horses (Season 4) (a return to form!).
• I jotted down some notes on Meta's two assets, Zed, and Migrating to Django 5.
• Opined a bit on productivity in My approach to GTD and PKM and Projects are things with steps.
• I let my mind with You should build this:, Notebook as marketing primitive and Consider the data product.
• I argued that Talking to customers is overrated.
• I thought led on Indie Rails and People & Blogs.
• Most importantly, I checked in on two weeks of parenthood.

Here's the rough pitch on Monster Sanctuary:

• Take the general framework of a monster collecting game (Shin Megami Tensei V is a good comp).
• Plug in a very lightweight Metroidvania framework (open world, but only kinda; monsters let you access certain levels and items, but it's fairly railroaded) and the aesthetics + plotting of a Saturday morning cartoon.
• Tune the gameplay perfectly, such that the game is never a cakewalk but never a chore.

That's it. Does tuning a squad of six cute pixel art monsters (each one of them with a unique and interesting skill tree) sound like fun to you? If so, Monster Sanctuary is for you. It is intensely designed for a specific kind of pleasure: there is very little "work" to be done (hatching eggs is instantaneous; respeccing is trivial; grinding or replaying rare encounters is easy). The plot is very akin to Crystal Project — almost self-parodic in its homage to its forebears, but never in a grating or cloying way.

The game was a delight, and feels like a Saturday morning as an eleven-year-old. I have never been more tempted to finish a game and immediately start playing it again on a randomizer.

(For those truly in the weeds: I finally blazed through the last third of the game on a Water-themed team that revolved around mass-application of Chill, damaging through Congeal, and out-lasting through shields + regeneration. If that's the kind of sentence that makes part of your brain light up, download the game immediately.)

(Epistemic disclaimer: there are few Extremely Big Tech Companies to whom I feel apathy more vividly than Meta. I had a Facebook account in high school and college and got rid of it at some point post-graduation, though I'd be hard-pressed to tell you when exactly that was.)

It was fun to listen to Acquired's six-hour episode on Meta. Ben and David have reached the Dan Carlin podcast local maxima for me: you can take some level of umbrage with their analysis (see, for example, The taste of beer) but their storytelling is so earnest and thorough it's hard not to have a great time listening to them.

Meta, in particular, was a fun episode, because listening to it felt not unlike taking a trip down my own memory lane and getting a better grip on my own relationship with social media (and how it's changed over the past two decades.) Some notes I jotted down:

• One thing that I lived through that I didn't quite understand until now was just how much of the Facebook "platform" was a feint towards a business model that never quite worked out, and how immaterial it became to their overall strategy once they really solved advertising. This is particularly noteworthy in 2024, as it contextualizes Meta's ostensibly developer/network-friendly efforts in Threads (for more thoughts, read Bluesky et al) and, conversely, a bit of a bull case for Bluesky itself.
• The concept of "reading someone's wall-to-wall" feels like a lifetime ago. The social primitive of a "wall" has technically not existed for a decade, now!
• As bullish as Ben and David are on Meta writ large, I think they are correct in saying that Meta's enduring two assets are:
  • the single largest network effect in human history
  • an organizational agility to be comfortable deploying as much energy, capital, and user activity as possible to what it considers useful.
• Relatedly, the open question of "what social interaction has Facebook actually developed or pioneered in the past decade" is a trenchant one, and one to which I cannot find a cogent answer.
• One rhetorical question: was Facebook inevitable? Which is to say: is Zuckerberg a Great Man of History, or if he decided to hard pivot into, say, video game design, would some other mega-corporation own a three-billion-MAU network graph? I have always felt the latter — I'm a dialectical materialist at heart — and yet there is something singular about Meta's agility and (I mean this not unkindly!) complete lack of scruples that I suspect would not play out in a parallel universe.

In closing, I am reminded of Zero to One's cute thesis about monopoly power being net-beneficial because it gives organizations margin and overhead to invest in projects that are otherwise unjustifiable in short-term competitive landscapes. Some of Meta's open source work is nakedly strategic (OCP, Llama); much of it is less obviously so (React, Presto, fbt).

Xerox was founded in 1906; 118 years later, its chief legacy is that of PARC — the personal computer, the mouse, the GUI, Ethernet.

Meta was founded in 2004, a time that this year more than others seems so distant as to be foreign. It is hard for me to prophesy what its stature will be in 2122, but it does not strike me as impossible to believe that its technological contributions will speak larger than its sociological ones.

Lots of kind words poured in as a response to My approach to GTD and PKM, and one question was asked so frequently that I decided to write about it.

Why is “Get mom a birthday present” a project and not a task?

GTD is very orthodox in what a “project” is: it’s anything that:

1. you think you’ll complete in the next year
2. requires more than one step to complete.

I used to think this was an overly broad definition for things like “buy mom a present”, “install weight rack”, etc and would just have them sit as tasks.

Over the past year, though, I've come to realize that this was not quite ideal. It's hard to read "buy mom a present" as a task when I'm looking for something idly to do between meetings or during weekly review; it's discrete, sure, but not so immediately actionable that I know exactly what to do or when to sequence it. (This is in contrast with, say, "buy mom a signed copy of Piranesi", where the action is clear and the time required is obvious.)

So: more things have become "projects". This has a couple second-order effects:

1. I'm forced to actually think about what the next step is for these smaller things, which is useful — especially the past month, where with Lucy the amount of executive function and mental capacity I have to actually do something is pretty limited.
2. At any point in time I have more projects active than I am used to, which is of course Not Ideal (context switching is hard! work in progress is bad!) but also truer than pretending I only ever have two or three things bouncing around my head at any given time.

(Again: none of this stuff has inherent merit; it's only useful insofaras it lets me spend my time more effectively and calm my mind so that I can focus on what I'm doing at any given point in time. But GTD does do those things, at least for me.)

Earlier this week, I stumbled upon this brilliant marketing-slash-documentation idea from SingleStore — notebooks as a first-party page! There are a handful of nice things about this idea:

• Very easy to fan out. You're not going to really run out of sample notebooks from which you can create pages.
• Easy to share and 'productize'.
• Lends itself obviously to both onboarding and existing users ("try it now" for people who aren't signed in, "use my API key" for people who are.)
• Doesn't require narrative or cohesion in the same way the same content as a blog post does.

I wouldn't be surprised if this doesn't become much more popular across developer tools businesses in the next few years.

One pernicious thing with writing about productivity and knowledge systems: you only change systems that aren’t working, and you tend to write about things during times of change. So most writing about productivity systems stem from people whose systems have failed them.

It is with this ironic prologue that I answer a question I've received from a few folks in reference to my usesthis.com interview:

Curious if you could share a bit more about how you use Things & Obsidian? I love Things but feel like I’m kind of holding it wrong. And haven’t yet been able to get into Obsidian.

Things

I have used Things for six years now; as of today, this is what my setup looks like.

I think Things is pretty much the perfect amount of organizational detail for most people: it encourages just the right amount of planning and administrivia without letting you delude yourself into thinking nested projects and deep meta-gardening of your work is anything more than cosplay.

The only change in how I use Things over this time has been how I organize my "Areas". Running a company, co-running a holding firm, being an active husband and father — my days and my schedules are much less neatly organized than they used to, and at any given point in time I have the temporal freedom to work on anything. This freedom is nice, but also a little bit difficult to wrangle: how do I know if I should be working on a new marketing initiative or setting up a 529 for Lucy? Breaking stuff up into my core identities as a person helps (though this is mostly just syntactic sugar around Home / Work / Side projects / Leisure, if we're being honest.)

Beyond that, Things' guide is really good. The only other bits of flavor I'd add:

1. Tags are useful in small doses. I only really use two: Phone and Errand.
2. Only use deadlines for things that are actually exogenous (customer-facing features, government regulations, birthdays, etc.) Otherwise, you run into a kind of urgency fatigue.
3. Being a founder means having a lot of stuff in the air, whether due to delegation or being blocked. For things that I'm waiting on in a non-temporal way, I prefix those projects with ×.
4. Conversely, "unfinishable projects" (blog posts to read, writing ideas, etc.) I prefix with ♾️.

Obsidian

I don't use Obsidian any more! I really love/loved it: it is a delightful piece of software to use, but everything I put into it I needed to share with other people (both technical and non-technical) — so off to Notion it went.

("But Obsidian for Teams is a thing", you might say! This is technically but not really true; it's not something that I can feasibly put in front of a tier one CS rep and expect them to be able to both consume and edit.)

("What about the stuff that you don't need to share with anything else?", one might ask. I posit to you: this information probably does not need to be recorded, and you probably have better things to do with your time.)

I use Notion for this now, and Notion is... fine. It gets the job done; everyone knows how to use it, cross-linking is really useful, the application is slower than I would prefer. It is not a decision or product that feels like it makes a huge impact in my life.

The goal is to do good work

In general, I am much more suspicious of PKM as a field than ever before. Andy Matuschak puts it well:

Most people who write about note-taking don’t seem particularly accomplished in their own fields, whatever those may be. In fact, most such writers aren’t applying their notes to some exogenous creative problem: their primary creative work is writing about productivity. These writers offer advice on note-taking to help scientists and executives with the challenges of their work, but the advice was developed in a context disconnected from those external realities.

My information-related problems in 2024 can be summed up in three ways:

1. I am often juggling dozens of projects of varying cadence, urgency, and aperture, and it's easy for me to forget certain things.
2. I have a lot of internal/tribal knowledge that doesn't neatly fit into some existing repository (codebase, blog, Slack) but should be shared with others.
3. It's easy for me to overfocus on short-term urgent work to the detriment of longer-term, more important but less time-sensitive work.

These problems were not the same as my problems in 2020; I suspect they will not be the same as my problems in 2028.

Solutions are only good insofaras they solve your problems; before committing to Yet Another App or Yet Another Methodology, ask yourself if really what you need is eight hours of sleep, a long walk on a sunny day, or a particularly good Manhattan and a particularly engrossing book. These things cannot be bought on Gumroad for $49 (with a cohort-based video series for an additional $299), but tend to be much more efficacious.

The advice might seem dated these days, but I think the stair step approach to bootstrapping is evergreen:

It’s much easier to sell an add-on to an existing ecosystem like a WordPress plugin, a Shopify app, a Heroku add-on – they’re usually small things to build, relatively inexpensive for customers to purchase, and you have built in discovery through the plugin repository or app store.   Other examples include Magento or Drupal add-ons, a Photoshop plugin, a WordPress theme, or an ebook or course.

These are all great examples for how to obviate marketing as a huge concern for a first product, but they also share a certain sense of finality that a full-fledged SaaS rarely does. Once you've built the thing and added it to the marketing channel of choice, it is done (modulo minor going concerns like changes to the underlying ecosystem, version updates, et cetera.) It is very hard to spend too much tinkering around the margins on a fifty page book or a Shopify <> Helpscout connector, and that inability is a feature that gently nudges you onto greener pastures.

This is a circuitous path to my suggestion of a new genre of entry-level product for the prospective bootstrapper, which I will call the data product. Here are some examples:

• A beautiful and meticulous dossier for various iOS devices and their screen sizes
• A dense tabular UI to poke around various AWS instance prices
• An even denser tabular UI to poke around SSD prices

These projects have many merits: they are small in scope, require few engineering decisions that could cause an otherwise well-intentioned engineer to bikeshed, easily marketable, and lend themselves to expansion into adjacent products.

A prior iteration of this site had a page called "Project ideas" that listed a bunch of things that I'd like to build. This was a good idea and useful in its own right (I got a few people to build companies and projects based on them, and it was a useful avenue by which folks could tell me which ideas were already implemented.)

I still haven't quite worked out how this current iteration of my site should handle these sorts of long-form mutable catalog-style posts: the whole thing is really organized around a central timeline, and in lieu of search or a colophon page its harder to designate a given post as an evergreen dumping ground. So instead, I'm just going to batch a few ideas every few months.

(If you end up exploring any of these ideas, please let me know!)

Fuzzy search atop git history

There's a lot of interesting work around applying LLM-powered search to software development workflows; many of these are inordinately ambitious (You gotta be able to taste the kool-aid), to the detriment of the more mundane but solvable problems. Things like:

1. "Which commit introduced the Automation model?"
2. "Which of my myriad stashes contains the exploration work I was doing on a new splash page?"
3. "What un-merged branches touch the markdown rendering engine?"

API wrapper around RDS Performance Insights

One genre of project that I stubbornly refuse to change my priors on despite a dearth of success stories (RIP Briefmetrics!) is: "UI wrapper around obscure/arcane/annoying but valuable FAANG API." RDS Performance Insights is a great example of this, and one can even purloin the great work done by Planetscale to find an early form factor that works well.

A better search around chat.db.

iMessage is one of the biggest social networks in the world; every MacBook has its entire iMessage history stored in a SQLite database called chat.db. It is wild to me that there aren't more projects that take advantage of this, given how annoying it is to actually search and collate one's iMessage history at scale?

...I always hammer on locked doors.

What's that supposed to mean?

The Anderson Tapes was released in 1971, placing it a decade after the original Ocean's Eleven (perhaps the first film to boldly ask: what if committing a heist was really cool?) and before The Conversation, a film more widely credited as introducing the concept of surveillance to the American filmgoer.

The Conversation only came out three years after The Anderson Tapes, and yet its treatment of surveillance is somehow much more postmodern and cynical; Coppola is interested in the interiority and paranoia of his characters, and it is taken for granted that everyone involved is already aware of their wiretapped lives (in no small part, I suspect, due to Watergate happening between these two films.)

This film, conversely, treats surveillance with a heavy-handed sincerity that could be construed as gimmicky ^[1] if it weren't so prescient. This is a straightforward movie with a straightforward message: we have spent the past decade building the Panopticon, and no amount of Scottish charm or ingenuity will purchase your escape.

Connery is great, of course, and there are bit parts to enjoy outside its use as a time capsule (a young, sinewy Christopher Walken; a Burn After Reading-esque denoument) but the enduring virtue of this film fifty years after its release is its wisdom in understanding exactly how and why the world changed, and to what end.

The total LOC delta to migrate Buttondown from Django 4 to Django 5 was +143, -150. (I was incentivized to do so because our search right now is quite slow, and the lowest hanging piece of fruit is to move some of the tsvector generation out of band, and I'd rather do that using the fancy new GeneratedField abstraction than rolling the SQL myself.)

The process was so boring as to almost not warrant a blog post:

1. Had to remove our usage of DEFAULT_FILE_STORAGE and roll it into the STORAGES dict which we were already using;
2. Had to bump up django-typescript-routes and django-safedelete to new minor versions (and for the latter create a new migration);
3. Had to trivially rewrite a few tests that were failing because we were incorrectly passing in some non-existent keyword arguments.

The one wrinkle was some still-unattributable change in Whitenoise / Django behavior; we were using CompressedManifestStaticFilesStorage and some of our vended CSS had, I guess, incorrect manifests? It's still not immediately obvious to me what the root cause was, but it was an easy enough fix.

Django 5's been in production for us for three days. A grand total of zero post-deploy bugs have surfaced.

There are few pleasures greater than getting to be profiled for an interview series that you've been reading for months, and last week I got to do exactly that.

To browse Manu's site — not just this interview series — feels a bit like walking on a quiet beach in autumn: there's a sense of peace and timelessness that is hard to find in the hustle and bustle of the increasingly-cacophonous internet. Fittingly, the interview is centered on the why and how of blogging:

It’s gone on a series of reinventions since then: my ability to consistently write has waxed and waned, but I keep coming back to this notion — particularly lately — that building artifacts under my own domain’s auspices is more durable and valuable than throwing them out into the algorithmic ether.

Whenever I really struggle with a book, I try to start from a place of authorial intent: what did the writer wish to accomplish with their writing? I find this particularly useful with postmodern + experimental work, as it lets me divorce my reaction to the form from my reaction to the work itself. Sometimes the answer is onanistic delight (If On A Winter's Night A Traveler, Pale Fire); sometimes it is meant to conjure a certain thesis about the exultatory power of art itself (Cloud Atlas, Ship of Theseus); sometimes it is meant to discuss the subjectivity of perspective and importance of interiority (Rashomon, The Hunting Gun).

Diaz' message with Trust is a melange of the latter two: art and capital are more similar forms of power than you suspect, he argues, and power has a tendency to occlude itself.

This is a bold organizing ethos — it is no wonder this book contended for and won a Pulitzer! — but it is hard to find much supporting material in the prose and character work.

We open Trust with a novella called Bonds, which we later understand to be considered not just (to quote the book itself!) a literary achievement that could have come from Edith Wharton or Henry James but a scathing exposé akin to those of Sinclair Lewis. Instead, it reads like a Wikipedia summary of the Carnegie family, with flat prose and characters sanded down to one-sentence flash cards.

This is what I've grown to call the Studio 60 on the Sunset Strip problem: it's really hard to depict diegetically what the reader must consider "a great work", whether its sketch comedy (in Studio 60's case) or bold, brilliant early twentieth century writing (in Trust's).

And once we've escaped the meta-fictional world of Bonds into the world of the Bevels, on whom Bonds is purportedly based, things are no better. Much post-Pulitzer hay has been made of Trust's desire to understand capital and patriarchy; this desire, if extant, is bloodless. Many sums, movements, and theories about capital, financialization, and soft power are discussed — they all seem as though Diaz spent his time trawling through Investopedia, and assuming his readers are more interested in vibes than barbs. (This inattention to detail transcends the financial aspects of Trust. Diaz also, not thinking readers of a memoir from a New Yorker writer would know what the Voynich Manuscript is, dedicates a two page exegesis to it; he also deploys gaslighting as a verb even though that phrasology only began in recent decades.)

The final section of the book — in which we are revealed that more than anything Trust is a murder mystery, and we get to hear from the woman behind the mask — is both the most controversial and the most interesting. Diaz is most interested in a sort of meta-feminism, revealing that Mildred orchestrated (really) the Great Depression. From an interview:

Mildred was not a victim, was not a sacrificial lamb. And I think the passage that you just quoted shows her agency and with agency comes responsibility, mistakes or the possibility of making mistakes.

I think this is where Trust succeeded the most — the visceral joy you get when suddenly you get to recontextualize all that came before, and various puzzle pieces lock into place.

But it's a shame about all the other stuff along the way.

Highlights

Today's gentleman is yesterday's upstart.

I am a financier in a city ruled by financiers. My father was a financier in a city ruled by industrialists. His father was a financier in a city ruled by merchants. His father was a financier in a city ruled by a tight-knit society, indolent and priggish, like most provincial aristocracies. These four cities are one and the same, New York.

"There is a better world,” a man said. “But it's more expensive."

You say that these numbers mean dial it down. I say they mean dial it up. You haven't gotten through. There are people you haven't persuaded yet. These number mean dial it up. Otherwise you're like the French radical, watching the crowd run by and saying, "There go my people. I must find out where they're going so I can lead them."

I ran into a great post from Karri of Linear on product management. Most of what he says warrants further discussion and digestion, but I wanted to chime in on the rhetorical question which prompted his lovely response:

Consider this: if “talk to customers” is the biggest secret to product success, then why aren’t more products successful? Why are so many founders unsuccessful? What explains PMs who’ve been talking to customers 5 times a week for years, without ever making products that win?

"Talk to customers" has become, to me, the same kind of truism as "charge more" and "users don't care about your codebase" — easy to deploy and sound clever in doing so, but dangerous in their banality.

At risk of deploying a metaphor (c.f. The taste of beer), customer feedback is something like a GPS: faster than driving aimlessly, slower than knowing the streets like the back of your hand. Especially in commodity/parity-style industries (like product management tools in Karri's case, or email in mine) customers make for good historians but poor futurists, and certainly they won't do the hardest and most important job of identifying your leverage points for you.

None of this is to say you shouldn't talk to customers: you should! But it should be neither the first nor the last step in your process: if someone needs to talk with people to figure out what to build next, it means they have insufficient vision; if someone needs to talk with people to figure out if something is truly ready for GA it means your org has insufficient conviction and process.

Customers are great at informing a product: reminding you of edge cases, blind spots, prior art, and so on. But there are many incredible things that can be built without information, and the annals of history are swamped with products that had very well-informed backlogs and yet no leverage or power to stop their own demise.

It is rare and difficult for a long-running series to reverse a downward slide. There are simply too many sources of gravity: writers run out of obvious plot lines and have to start re-hashing, Flanderizing, and escaping the confines of the show's existing logic; actors change, and audiences grow tired of what was once novel; it is simply hard to capture lightning and put it back into the bottle, and the commercial demands of the television industry incentivize showrunners to turn their works into shambling ghouls (another year of steady work for the crew, another year of solid residuals, another year of fun with coworkers with whom you've grown fond) rather than a surgical and cohesive narrative arc.

(All of these things are true of books series as well: take, for instance, the Berlin Game nonology which started with promise and ended with Deighton left with no other choice but to raze his characters [and goodwill] to the ground.)

Slow Horses bucks — or at least bucked — this trend. Its fourth season is a triumph: it rights every slight misstep of Slow Horses (Season 3) and Slow Horses (Season 2) (both solid seasons in their own right, but not nearly as great as the gemstone first season) and delivers the best six hours of thrilling, compelling spycraft in a long time.

Some miscellaneous notes:

• One of the keys to Slow Horses' success is the legitimacy of its stakes. There's no Game of Thrones-esque flippancy with which characters are killed off less out of narrative cohesion and more out of a desire to shock the user, but nobody (besides, presumably, Gary Oldman's Jackson Lamb) is safe from death: this is something we're reminded of every season, and it gives a sense of actual danger and urgency to every shootout or chase.
• Speaking of Jackson Lamb: this season probably had the least screentime from Oldman. This can be a dangerous gambit — it paid off here, and his absence (modulo the handful of convenient deus ex machina opportunities he's afforded) is felt but not painful.
• Spy stories must thread a very tricky needle when it comes to realism. It's really hard to be entirely grounded in craftwork and realpolitik unless you're le Carré or The Americans, and it's also hard to be bombastic and exciting in the traditional language of television action sequences without feeling like you've suddenly entered a different, sillier show. (This was, I'd argue, the main flaw in Season 3: we suddenly entered a Call of Duty commercial in the back third of the season.)
• Season-long arcs dedicated to flushing out a character's backstory can, similarly, be hit or miss: shows need to earn an audience's trust that we actually care and empathize with them enough to follow them down unexpected corridors, and actors need to be able to shift from being relatively one-note to full-fledged protagonism. Jack Lowden passed with flying colors.