Had a blast live-coding some experimentations with Steve and Shovel yesterday using Val Town. (If you haven't used Val, well, watch the stream — think live, zero-deploy code snippets that can be arbitrarily extended and executed.)

Reflecting on the experience, the most exciting part of the entire hour for me was using Townie, Val's AI live-coding tool. I was — not skeptical, but agnostic — about it (I know exactly what I want to write! What's the point in having an AI potentially-lossily do it for me?) and, as has been the case many times over the past two or so years, my tepid expectations were blown out of the water.

At this point, I'm comfortable using Claude to generate snippets for me as proof of concepts of where I want to go with a larger project, and I'm happy to offload certain menial and easily-verifiable tasks to Cursor (see Using Cursor to port Django tests to pytest), but Townie was the first time I've felt like a tool was both faster and more efficacious than I could have been.

Watch the full stream

One third of the way through The MANIAC, I found myself wondering why this book was not more popular: it seemed to be a perfect storm of formalism and postmodernism (it being told in a fugue-like oral history), scientistic reckoning (suddenly in vogue thanks to Oppenheimer), grappling with AI and AGI explicitly.

By the time I finished the book, I think I arrived at an answer: it's just not that fun or interesting of a read! The ostensible pleasure of a Greek chorus of larger-than-life scientists deifying von Neumann fades once you realize how the arc and voice of every character is so thin and uniform (compared with, say, HHhH or Autobiography of Red, where the experimental structure adds to the storytelling and diegesis rather than acts as a bit of showmanship). It is clear to understand why Labatut chose to write this book, and one quickly groks the thesis that the aforementioned Oppenheimer arguably delivered more succinctly and persuasively (our current runaway train of scientific progress is driven less by the desire to understand and improve the world and more by the desire to master it for the sake of mastery).

But you are left with prose that is all text, no subtext — the final part of the triptych perhaps most emblematic of this flaw, a New Yorker-tier play-by-play of Lee Sedol's five-part match against AlphaGo. It is a fun story, especially if you are not burdened by understanding of Monte Carlo tree search. You are told, page by page, exactly how to feel about the entire thing: awe, wonder, despair, hope, dread. Labatut takes care of all of that for you; nothing is left to interpretation.

Highlights

“All processes that are stable we shall predict. All processes that are unstable, we shall control,” he said, and I, for one, believed him, because I’d never seen him be wrong about anything else before.

Technology, after all, is a human excretion, and should not be considered as something Other. It is a part of us, just like the web is part of the spider.

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.

Kevin Twohy has a list of heuristics for new projects/clients, and my favorite is simple:

No Bozos. Simple policy. No exceptions. You know it when you see it.

Every founder has a story about the time that they ignored the red flags and bent over backwards for a particularly standoffish or problematic customer/prospect/client/hire. It's easy to get lost in the details of the anecdata (was it a bad policy to even entertain the request? was the user technically correct, just a jerk about it?) and therefore slightly more hard to form specific policies to prevent that exact genre of scenario.

But it's very easy to make a policy of "no bozos". Everyone innately knows what it means.

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.

---

1. One of the few things that did not age well was the sound effects as we smash cut from one scene to another. ↩︎

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.

Read the full interview

Next page