Who is the target audience for this book? The most charitable answer I can give is "people who are productive individual contributors that have literally never worked in a team setting before"; a less charitable answer (but one that I suspect is more accurate, both towards the authors' aims and the average reader's characteristics) is "people willing to buy Yet Another Management Book because it has the GTD stamp on it."

Certainly, if you have read any sort of literature (and by literature I am mean to be broad enough to include, like, blog posts) around management the vast majority of this book is of no use. Lamont and Allen offer advice of the genre: "meetings should always start on time", "it's important to have clear lines of communication", and "knowing who owns what is important". Nothing is incorrect; everything is anodyne.

(Lamont even has an aside towards the end of the book about how the editor commented on the draft as being "particularly lean" and not needing much editing, trying to spin this as a good thing and that the book was a useful primer to revisit over the years.)

I am being particularly critical of this book, because it left a particularly poor taste in my mouth. I think there is a real need for a practitioner's guide towards GTD in a group setting (how do you integrate tooling? how should you revise your understanding of delegation?) and, modulo a too-short appendix, none of this is addressed and indeed David's main contribution to the book probably accounts for all of ten pages (five of which are simply him saying "I agree with what Ed said".) It's certainly not harmful, but it takes everything I loved about GTD (directness, idiosyncracy, concreteness) and excised all of that in favor of table-stakes collaboration ideas that most competent people are already familiar with.

Do not buy this book!


It’s tempting to compare Cloud Atlas to its obvious metafictional forebears, If One A Winter's Night A Traveler, The Years of Rice and Salt being chief among them. [1] But almost from the book’s onset my mind kept on travelling back to an unlikely comparison: Chrono Cross.

Not just because of the incredibly ambitious, vaguely-multi-dimensional aspects of the plot and structure, nor for the pleasant and somewhat under-utilized grounding in a distinctly island world.

But because Chrono Cross’s much-ballyhoo’d “dynamic speech engine” (that purported to dynamically alter the story and various cutscenes based on which of the thirty possible characters — a huge amount for the PS1 era! — were in your three-person party at any time) amounted to stuff like this:

Pierre:
   Ah, oui?
   Is this really
   a ghost ship?

Nikki:
   Could this really be
   a ghost ship...?

Korcha:
   This ain'tCHA ordinary
   ghost ship...

Razzly:
   I've never been on a
   ghost ship before...
   I'm fairy scared...

Mel:
   Wow! So this is
   a ghost ship!?

Greco:
   Is this...
   a ghost ship,
   amigo...?

Guile:
   What is this...?

Glenn:
   So this is
   the infamous
   ghost ship...?

Macha:
   Is this whatCHA
   call a ghost ship?

Doc:
   I sense human activity
   aboard this ship...

Luccia:
   Is dis a ghost ship?
   ...Highly illogical.

NeoFio:
   Is this really a
   ghost ship?

Which is to say: changes in syntax without changes in anything else. (And a feat in its own right, but falling short of what you might hope.)

Cloud Atlas’s central flaw (or flaws) is that, frankly: the individual stories are not that good, in terms of plotting and prose. Mitchell does a mostly persuasive job of the mechanics — the period pieces scan as period pieces, but the authorial tone and beating of each piece is so flat and one-dimensional that there is very little to be excited about besides thinking about the threads binding the chapters together. [2]

Compare this to the titles which Cloud Atlas usually is bucketed with: the two aforementioned (two of my favorites, to be sure); Pale Fire; A Visit From The Goon Squad. All of these books are lauded not just for what they do outside the form but what they do within it, and Cloud Atlas reads — for a majority of its time — as pulp. [3]

Conversely, I thought the metafiction worked quite well. I went in expecting a Lost-style puzzle box, with very concrete clues and ties explaining how everything added up to a single gestalt; Mitchell denies you such hedonistic pleasures, and you’re left with a more ethereal understanding of these characters and their relationships — their being united in a struggle against power, their solace in consumption of their predecessor’s literature, and so on. (Though even then, the author giveth and he taketh away. I think it was clever, and correct, to lampshade the implausibility of reincarnation and recurrence to deny the easy answer of “ah, this is the same soul in different bodies”, and yet Mitchell felt bizarrely and amateurishly compelled to make sure every single character references the title of the book, a true That’s Chappie moment.)

Mitchell has, I think, very lovely and sweet things to say about the human experience: he believes in the importance and virtue of emancipation, he believes in the exultatory power of art, he believes in redemption.

Cloud Atlas is summed up by its ending lines:

My life amounts to no more than one drop in a limitless ocean. Yet what is any ocean, but a multitude of drops?

A beautiful metaphor, clumsily delivered.


  1. And, to be clear, both of these are much better pieces of literature than Cloud Atlas. ↩︎

  2. A single exception to this: Robert Frobisher’s section. Frobisher’s character is not just the most interesting and surprising of the entire lot but also by far the most entertaining. ↩︎

  3. You can make, I suppose, the argument that this is intentional — one of the books is literally pulp. ↩︎

Highlights

Glass & peace alike betray proof of fragility under repeated blows.

To fool a judge, feign fascination, but to bamboozle the whole court, feign boredom.

Men invented money. Women invented mutual aid.

To wit: history admits no rules; only outcomes.

Implausible truth can serve one better than plausible fiction, and now was such a time.


How do you view a series of books — or any periodic work, like a long-running TV series? Do you let a single work determine your view of the series, or must you evaluate the whole series as a gestalt with each passing entry?

Spy Line is, at it's heart, a dismantling of the four books leading up to it (with Spy Sinker, its sequel, being a near-callous mockery and derision of those books.) Two thirds of the book are fairly banal and much in the "Samson way" that so comfortably dominated the series (petty, entertaining politics; brutish and clever spycraft; pleasant caricaturing of the British intelligence services) and the other third reveals that the entire plot leading up to these moments have been sleight-of-hand, and every inch of drama we've been subjected to has largely been a feint and a ruse.

A feint and a ruse. But a waste of time? This is an interesting question, and it largely depends on your faith and trust in Deighton. You can charitably interpret this shift as a very wide-lens postmodern critique of spy literature — Bernie's gullibility and snookerdom is a metaphor for our own, and for the misguided sense that any one well-meaning person can make a legitimate difference in late-20th-century global dynamics. Or you can uncharitably interpret it as something like: Deighton loved writing the first trilogy, and wanted to spend more time with these characters, so he sat down and thought about how to make a second trilogy, but in doing so he burnt most of his forest to the ground.

As much fun as I've had with Deighton's writing, I have to go with the latter interpretation. You can point to little hints and clues in the original few books that this was indeed all part of his master plan, but characterization makes no sense, and other things along the fringes don't lend Deighton much more credibility — the entire stamp collection escapade, the way in which Samson's red notice is entirely forgotten and everyone pretends it never happened. Indeed, this feels like a writer's room trying to figure out a way to make a compelling fifth season of a show that should have ended after its third: you don't have to dislike the characters to know that the time for their exit has long-gone.


A handful of folks sent me this quip from Nate Silver a few days ago:

Slightly against interest to admit this (I don't want more competition lol) but I think we're still probably a year or two away from Peak Newsletter. It's just a really good distribution mechanism for certain types of writers. It does take some time to build up momentum, though.

One of the things that makes "Peak Newsletter" as a concept both interesting and slightly pernicious is that the growth of newsletters is somewhat nebulous and amorphous compared to other similar content industry booms. [1] For some, P.N. refers to a focus on individual brand over masthead; for others, it refers to emancipating oneself from the distribution + growth channels afforded by traditional media and social media in favor of SMTP; for others, it refers to the very calculated paid acquisition-heavy approaches of buying subscribers and recouping costs on advertising.

With that in mind, here are some scattered thoughts.

  • One of the few legitimate things that has changed over the past decade is that it is much easier to solicit paid subscriptions thanks to services like Stripe. This is a technological shift rather than a cultural or consumptive one, and as much as I hate the language of "the creator economy" it does get at a meaningful point: part of the role of traditional media apparati is to provide financial tooling, and the marginal value of that role is diminishing-to-none.

  • Every large media startup conveges on a mission of "change consumer behavior en masse". [2] These missions fail: Netflix did a great job destroying cable, but I don't think they were comparatively successful in net creation of television consumption; every single podcast startup or podcast-heavy media platform quickly discovered that all the money in the world couldn't get a financially non-trivial segment of listeners to start becoming rabid podcast consumers. Beehiiv and Substack's mission are both some variant of "we will become a billion-dollar company by not just capturing the existing content landscape but by growing it significantly", and I am similarly skeptical that a meaningful amount of people will dramatically change their overall consumption habits.

  • One source of jet fuel for the podcast boom of yesteryear was an ocean of capital that went into advertising; the amount of money spent on advertising was justified less on hard ROIC and more on the lack of easy attribution due to the inherent nature of podcasting, and once clear data and metrics emerged a lot of the willingness to throw money at legions of Casper ads was lost (and, as a second-order effect, so was a lot of the willingness to spin up dozens of new podcasts to capture the revenue from said Casper ads). We are already seeing the same effect happen in email advertising: sophisticated vendors are only looking at intent/conversion-level data, and the emergence of co-reg has turned subscriber count and open count into a vanity metric for "platform-based" publishers.

  • The trend of every social media platform is towards a capricious algorithm that intentionally penalizes long-term relationships and rewards short-term spotlights. This is antipodal to email subscriptions; creators of any type have more incentive now than ever before to try and capture their audience before TikTok yanks them away.

Are we at Peak Newsletter? Probably not. I think — to steer this into the realm of concrete and falsifiable — that more people will spend more money and time on individual writers three years from now than they do today. I suspect we will see a lot of "pullback", to borrow a financial term, over the coming years, as "content arbitrage"-style businesses suddenly no longer have a viable business model due to the deflation of advertising, but it will continue to get easier and more profitable for great writers to build their own audiences and monetize their work.


  1. In general, I think a pretty easy way to predict much of what will happen in the newsletter landscape is to look at what happened five years earlier with podcasts. ↩︎

  2. Most famously quipped by Reed Hastings, who said Netflix's biggest competitor is sleep. ↩︎


Spy Hook forms the start of a second trilogy of books in the "Bernie Samson" series by Len Deighton; the previous book, which ended the first trilogy, was London Match, which I finished reading a few months ago and wrote:

I think I'll take a (long) break before resuming the nonalogy of these books, but I'm happy to have blitzed through the first three: they were both gripping and rewarding, and Bernard Samson makes for a delight.

I wrote in that book's review that there was a whiff of the workplace sit-com in reading the trilogy; there is a realism and propulsion in these books, and in unwinding the narrative and realpolitik, but also a deep comfort in checking in with your ol' pals in MI5 and the Berlin field unit. This sense of — for lack of a better term — amity (reminiscient of Slow Horses as well) is a nice contrast from the work of le Carré whose theses is often about the transactional and callous nature of this work, and yet the repetition started to hit me a little bit with this one: how many times can Bernie accuse and then vindicate the same colleague? How many times can we be surprised by one of Werner's romantic flings?

Add to this the sense that — more than any of the preceding three books — Spy Hook is not a self-contained story. It is perhaps an overlong first act, but there is no satisfying conclusion beyond a Dumas-esque "gotta read the next one!" ending. And, of course, read the next one I will — but besides getting to chat again with our old friends at the office, it's hard for me to say that I learned or picked up anything new from this book that I hadn't from the originals.


A really fun and pleasant movie that was never surprising and extremely fun, start-to-finish. This is a by-the-numbers bildungsroman — two teens, a cool girl next door, a deified older friend, hijinks — and you know exactly what plot points are going to get and they are delivered capably. The script is modern in a way that betrays its theoretical nineties setting (with apologies to the director, Adam Carter Rehmeier, but unless you were really ahead of your time I don't think the Juno-esque bon mots were really that autobiographical!) but is sold so convincingly and brightly by the pair of leads that you don't mind at all.

Does this movie have revelation? I'm not sure about that. Conor Sherry's performance — and his visceral sense of alienation — has a whiff of the sweet, relatable angst that I loved so much about The Secret History and even the first few bits of The Perks of Being a Wallflower. Much of the center does not hold: Mika Abdalla's character is a little too vacuous and the final few beats are just so neatly wrapped that it's hard to really come away from the movie feeling like it's anything better than a more modern Sandlot (which is not that bad of a final analysis, to be clear!)

(More than anything, this movie reminded me of why I loved Everybody Wants Some!! so much: Linklater created a world that was warm and sweet and anodyne and had you exit that world in a way that felt novel.)


Andrew Rea with an interesting and increasingly familiar take about how AI will disrupt software-focused private equity:

Distribution and brand moats can protect your legacy products for a while (esp in enterprise) but eventually you get lapped by competitors with better products, service, pricing, etc. Software is too competitive and changes too fast for this model to work in 2024.

I think most of the takes around AI and software (c.f. Chris Paik’s thesis on the same thing) all center around the same few starting lemmata:

  1. Over the past twenty years, the fixed costs required to build and distribute software have gone down.
  2. AI purports to accelerate that trend: maybe significantly, maybe in totality. [1]
  3. Therefore, software qua software as an asset is going to round down to zero over time, and software companies will differentiate themselves on things outside of core functionality.

From there, they diverge into two main camps:

  1. This trend is good for incumbents, because incumbents have data, brand, process power, and other strategic assets that don’t get rounded down to zero. (I think this conversation between Des Traynor and Patrick O’Shaughnessy is a particularly good articulation of this thesis.)
  2. This trend is bad for incumbents, because incumbents rely too heavily on customer inertia and revenue capture and are systemically disinclined to innovate at the rate that a disruptor would. (See Andrew’s essay which opened this post.)

I think these conclusions are less contradictory than they appear. It is getting easier to write and deploy software en masse, which makes it harder for established organizations to stay differentiated on functionality alone; but those organizations can now, at least in theory, use and deploy their other assets for more interesting ends, and a lot of the capital expenditure inherent in significant engineering work suddenly becomes much easier to pencil out.

That being said!

I think it is very easy to look at rate of change and the speed and polish with which startups are building impressive bodies of work and...skip to the epilogue, where they’ve triumphed over the incumbents of the world who are more focused on cash flow extraction than customer value creation. The reality is: the number of industries where people are making retention/churn decisions based purely on functionality alone is smaller than you would think at first glance; the strategies deployed by Thoma Bravo et al (aggressive cross-selling, aggressive contract durations, rolling up to drive down unit economics) are already the right ones, insofar as we define “the right ones” as “the ones that maximize long-term enterprise value.”

Whether you’re an incumbent or a new market entrant, it’s very important to think about strategic long-term moat, points of customer acquisition, tail risks, and useful levers: which was also true in 2020, and 2010, and so on.

Any argument otherwise is science fiction: interesting and thought-provoking but rarely useful. (And remember to taste the kool-aid.)


  1. Epistemic disclaimer: I think our distance from “instant, Matter Compiler-style AI-built software products” is so far away from the present that it doesn’t really warrant serious discussion ↩︎


There’s a nascent trend of releasing ostensibly-private material (changelogs, public wikis, handbooks, etc.) to the public as a bit of a marketing push. This is essentially a form of debt, to the extent that you’re taking a lump-sum payment now in exchange for the implicit cost of keeping these things “up to date” indefinitely (and if you don’t, it’s immediately obvious: nothing gives me the ick more than seeing a changelog whose last entry was six months ago or a “internal handbook” that hasn’t changed since it was launched.) There are some teams that do it well (GitLab and Significa come to mind); there are other teams where it fairly vividly reads as “we haven’t figured out a marketing channel yet, maybe this will do the trick.”

Buttondown’s most pernicious form of content debt is the more conventional kind: docs have screenshots that are out of date, blog posts reference features that have been moved or renamed, comparison pages are anchored on old pricing, et cetera. It all boils down to some variation on vestigiality: you publish a thing that doesn’t have a direct line of communication to the source of truth (whether that source of truth is “a YAML file containing pricing plan information” or “the live production-level codebase” or whatever.) A lot of my strategic work the past month, and in the month to come, is focused on widening those lines:

  1. Replacing screenshots in the docs-site with automatically-generated iframes;
  2. Replacing hand-written API examples with ones built by httpsnippet and verified in CI;
  3. Building out a single-source-of-truth demo site with reasonably, semantic fixture data in support of both above efforts.

This is yeoman’s work; it can be fun to puzzle out efficient solutions, but it’s certainly hard to justify on the grounds of immediate business value alone. But, like investing in paying down technical debt, it earns its keep over the course of years if not months.

Moreover, whenever I’m poking around interesting marketing or content projects the thing that I ask myself first is: “what is the cost of maintaining this accurately and indefinitely?” Which, you know, is a fairly anodyne and 101-level question — but I’m more used to asking it about code than content.

(It also strikes me that this kind of thing is much more fertile ground for better developer tooling. I don’t think I’ve talked to a single founder who feels really good about their process of making sure docs stay up to date.)

Lastly, the organizations I’m most envious of are the ones that sidestep this problem entirely by shipping their application as their marketing site: Rows, Typefully, I’m sure there are others. Do these experiences convert at a rate as high as a dedicated buildout might? I don’t know, but there’s a single-mindedness and clarity that I admire.


Glyph (whose writing and contributions to the Python ecosystem I am deeply grateful for) wrote Against Innovation Tokens yesterday:

In 2015, Dan McKinley laid out a model for software teams selecting technologies. He proposed that each team have a limited supply of “innovation tokens”, and, when selecting a technology, they can choose boring ones for free but “innovative” ones cost a token. This implies that we all know which technologies are innovative, and we assume that they are inherently costly, so we want to restrict their supply. That model has become popular to the point that it is now part of the vernacular. In many discussions, it is accepted as received wisdom, or even common sense. In this post I aim to show you that despite being superficially helpful, this model is wrong, and in fact, may be counterproductive. I believe it is an attractive nuisance in computer programming discourse.

I find his argument unpersuasive, for two reasons:

  1. His minor quibbles about CBT [1] are enumerated as “it’s incorrect to assume that new technologies have more overhead than old technologies; it’s incorrect to assume that new technologies are harder to learn than old ones; you shouldn’t make technology choices based on how easy it will be to hire people, since you’ll need to train them up regardless.” I think that third point is a nuanced and interesting one, but the whole point of CBT is that there’s no way to truly understand the difficulty of a newer technology without the experience of using it in a deployed environment, and doing so is risky.
  2. The larger metaphor he uses to illustrate the downside of CBT — deploying Haskell and then wrapping it in Ruby to limit the blast radius — misses the fundamental question one should ask, which is: “do we actually need to use Haskell in the first place?” I think search is a really useful example here because it's something that many engineering teams have encountered — the process of spinning up an ElasticSearch instance (or something similar) and suddenly having to deal with an entirely new caste of problems versus pouring time and effort into improving the existing relational database to make it handle search-shaped workloads.

However, he introduces what I think is a very useful concept: boundary tokens. He writes:

That is to say, rather than evaluating the general sense of weird vibes from your architecture, consider the consistency of that architecture. If you’re using Haskell, use Haskell. You should be all-in on Haskell web frameworks, Haskell ORMs, Haskell OAuth integrations, and so on.1 To cross the boundary out of Haskell, you need to spend a boundary token, and you shouldn’t have many of those. ... When people complain about programming languages, they’re often complaining about how many different kinds of thing they have to remember in order to use it.

I think this is absolutely correct, and the north star a nascent engineering organization should be pursuing is something along the lines of: how much fixed-cost (onboarding) and marginal-cost (context-switching) time and energy is required to be able to touch every single part of the codebase?

This is hard to quantify, but it's one of those things for which vibe-checking is very effective. At Buttondown, we've got a core app written in Vue and a bunch of smaller auxiliary microservices running on Next; these are separate frameworks, sure, but it's all Typescript, and plexing between the two is much more trivial than if you had to hop over to Phoenix or Rails something entirely different.


Glyph also talks about the anti-intellectualism inherent in CBT, an argument to which I'm sympathetic. If you were to take CBT to its rhetorical and logical extreme, you'd never use anything new; doing so is a sort of bet against the fundamental promise of technology, which is that things are (jaggedly, but monotonically) only getting better over time.

First off: I think both the accusation and the reality are kind of true. Kubernetes is the go-to punching bag for this kind of thing, but it is important to internalize, deeply internalize, that many new technologies are not going to improve the rate at which the median technology company can create enterprise value. (For more on this, read Use Rails.) If you are a senior member of a technical organization, your job is to keenly and efficiently evaluate various new technologies on the bleeding-edge, to find the rare exceptions where that is not the case.

Second off: I do think it's important to have escape valves in technical organizations so that you can evaluate new technologies in a manner that is less operationally onerous than prod, but more legitimate than a hackathon or side-project. Good candidates include: internal-facing tools, microservices that can be interfaced with over REST, engineering-as-marketing buildouts.


  1. Choose Boring Technology, not, uh, the other one. ↩︎


Here is the entire gist of the book: use envelope-based budgeting (as made famous by, at least in my life, You Need A Budget) for your business. Allocate, say: 45% of your business towards owner's compensation, 10% towards profit, 15% towards tax, 30% towards operating expenses. Use these target percentages to back your way into sustainable salaries / cost structures and grow your business within these parameters, rather than shoveling any liquidity back into the business (because that will cause you to lose discipline and line-of-sight on actual business health.)

I think the book's thesis is good, and even though the true business model of the book is upselling you towards a professional consulting network (not unlike The E-Myth Revisited) it's a quick and easy read — a rare business audiobook where the reader (the author!) enhances rather than dulls the whole thing. I also don't think I'm quite the right target reader, which is not the fault of the book nor its writer.

Of course, there are quibbles:

  • The author literally says to throw away the entire institution of GAAP because it's "funny money" and then has to spend the back third of the book re-building GAAP from first principles to handle things like recognized revenue and capital expenditures;
  • The business tactics that the author tries to emphasize will emerge from the "Profit First Mentality" are thin-to-threadbare, the best (worst?) example of which being "you absolutely can double your output at half the cost: an example is how I did it in my business, which I cannot elaborate on due to Trade Secrets" [1]
  • Mike totally mischaracterizes not just the tragedy of Frankenstein's monster but perhaps the entire message of Frankenstein [2]

All in all, I can't fault this book too much — it was quick, entertaining, and responsible for me making a positive change in my business (I am going to split out my omnibus checking account in Mercury into a bunch of sub-accounts!) I do not think you will get better at business strategy after reading this book, but it is something I would recommend to people who are losing sleep over their business's cash flow.


  1. I don't even disagree with the thesis — constraints breed creativity! It was just lazy rhetoric. ↩︎

  2. This is, to be clear, a joke. ↩︎


A deeply real and viscous sort of thriller. There were so many naturalistic fluorishes — long, languid shots on our two protagonists in deeply grimy places, bursts of the kind of quiet human humor that rarely brighten a serious script, casual lapses into German and authentically implacable accents — that this felt less like the taut production of Klute or the painterly opus of Ripley and more like something from le Carre or Len Deighton.

Hopper and Ganz are terrific, two, as a pair of leads who convince you both as friends and enemies alike.


Inspired by Adam Johnson's test for pending migrations, and of course in conversation with my own love of weird tests, I offer a similar concept: a test for finding stray print statements in your codebase, with a ratchet array for stuff to ignore.

import glob

PATH = "**/*.py"

irrelevant_paths = (
    "/commands/",
    "node_modules",
)

def test_no_print_statements() -> None:
    all_files = glob.glob(PATH, recursive=True)
    relevant_files = [
        filename for filename in all_files
        if not any(
            irrelevant_path in filename
            for irrelevant_path in irrelevant_paths
        )
    ]
    files_with_print = [
        filename for filename in relevant_files
        if "print(" in open(filename).read()
    ]
    assert not files_with_print, f"Print statements found in {files_with_print}"

I anticipate a concern being "this is slow! you're opening thousands of files!", to which I reply: this test is faster than any other test you have that touches a database. That being said, I'm sure there are edge cases or ways to improve it, so please let me know!


I watched Gary Bernhardt's talk on static routing back a few years ago and — I'm not sure if I would call it formative, but it stuck in my craw as a platonic ideal of sorts, as something I couldn't really justify adopting within Buttondown but really wanted.

I built out and open-sourced some feints in this direction — see django-typescript-routes, which provides a TS router generated from a Django backend — but that's not quite the same thing, and time and time again I found myself in the position of pushing bugs that would have been caught if I had a typesafe router in Vue.

Tanner Linsley makes the pithiest possible case for such an abstraction:

Too many people don't realize they're managing the most critical state of their application in a /string?Record<string, string># string type. 🤦‍♂️

I was thrilled to stumble upon the very poorly named unplugin-vue-router earlier this year and resolved to spend some time hacking with it to see if it was worth the cost. It was, and I'm glad I did it.

How it works

Vue Router is a very simple abstraction: you define a list of routes (where a route is a component and a matching path and some metadata), and Router routes for you. Something like this:

import { createMemoryHistory, createRouter } from "vue-router";

import HomeView from "./HomeView.vue";
import UserListView from "./UserListView.vue";
import UserDetailView from "./UserDetailView.vue";

const routes = [
  { path: "/", component: HomeView },
  { path: "/users", component: UserListView },
  { path: "/users/:id", component: UserDetailView },
];

const router = createRouter({
  history: createMemoryHistory(),
  routes,
});

Nothing particularly magical or fancy. The Faustian bargain you sign with UVR, though, is that in order to get typesafe routing you must also adopt file-based routing:

  • ./HomeView.vue becomes ./index.vue;
  • ./UserListView.vue becomes ./users.vue;
  • ./UserDetailView.vue becomes ./users.[id].vue.

And then the above mapping file gets magicked away:

import { createMemoryHistory, createRouter } from "vue-router/auto";

const router = createRouter({
  history: createMemoryHistory(),
});

I actually don't mind the file-based routing, but it made adoption much more painful — it was very difficult to do a piecemeal migration, and it basically ended up as an omnibus PR touching every single view in the application. (Though that PR was made much safer by the fact that now all the routes had type information!)

You might also notice that the third file was not /users/[id].vue, but /[users].[id].vue. UVR handles nested routing for things like modals differently than I was used to in Next; you nest modals by plopping them in directories in a way that is logically coherent but still takes a bit of getting used to.

Three months later

By the time I was truly waist-deep in the UVR migration, it felt like it was:

  1. Too late to turn back;
  2. Perhaps not worth all the effort just for some type safety.

Three months later, though, I am quite glad I did it. It was a pretty big up-front cost, but has saved me many times over from pushing bad code, and the doubts I had about the approach being 'janky' and messing with VSCode have not borne out.

If you're using Vue, highly recommend. (Now all I need to do is get a similar abstraction for query parameters!)


First of all, a bit of context-setting: I am not quite yet a father of a daughter, but I am four months out from becoming one, and I suspect my reading and emotional attachment to this book — and to Nell, as charming and plucky of a slightly-unbelievable-but-still-winning bildungsroman protagonist as one could hope for — are so heavily tempered by this book that quibbles I might have had even a year or two ago are sanded down into oblivion.

The reason for this is that in much the same way that Snow Crash purports to be a cyberpunk book but is actually a book about communication and language, The Diamond Age: Or, A Young Lady's Illustrated Primer purports to be cyberpunk but is chiefly interested in education and parentage. Stephenson's book contains two parts (a decade-long lacuna separating the two), and each part is concerned with a single question:

  1. What social ills might exist in a post-scarcity world?
  2. How do we raise children to be interesting, happy, and virtuous?

I did not find either either side of Stephenson's first question to be particularly revelatory: the yadda-yaddaing of nanotechnology and its impacts felt thin and post-hoc to me, even if there were some flashes of brilliance in isolated asides. But where Stephenson was both clearly more interested and more persuasive was when he began to shift the narrative to focus on the triad of young girls who had received the primer, and their varying divergences.

Moreover, the device of the Primer carries with it a level of stylistic flourish difficult to find in other pieces of his work. Princess Nell's escapades served well to shepherd us through the obvious paces of character development while offering something relatively novel; the Turing Castle chapter in particular (and thereafter) was a legitimately fun (albeit, of course, campy) way to deliver what could have been dreadfully boring material.

This book suffers from the classic Stephenson tropes:

  1. As much as I think Stephenson lovingly writes Nell's character, I can't escape the feeling — much like in Snow Crash — that her sexual assault feels oddly transactional, as a heavy-handed way to weave villainy into a narrative that is in general pleasantly bereft of cartoonish intentions;
  2. The book ends with a beautiful visual metaphor that occludes but does not fully disguise its incoherence.

But — this book gave me so much to digest and ponder and enjoy, and it has not fully left my head since reading it. There are two types of science fiction: the ones that get better with age and the ones that get worse. This is the former.

Highlights

“Yet how am I to cultivate the persons of the barbarians for whom I have perversely been given responsibility?" … "The Master stated in his Great Learning that the extension of knowledge was the root of all other virtues."

Hackworth was a forger, Dr. X was a honer. The distinction was at least as old as the digital computer. Forgers created a new technology and then forged on to the next project, having explored only the outlines of its potential. Honers got less respect because they appeared to sit still technologically, playing around with systems that were no longer start, hacking them for all they were worth, getting them to do things the forgers had never envisioned.

“There's only zero of you,” said the Queen of the Ants. In ant arithmetic, there are only two numbers: Zero, which means anything less than a million, and Some. “You can't cooperate, so even if you were King, the title would be meaningless.”

But as many first-time fathers had realized in the delivery room, there was something about the sight of an actual baby that focused the mind. In a world of abstractions, nothing was more concrete than a baby.

He nodded in the direction of China. "Been doing a bit of consulting work for a gentleman there. Complicated fellow. Dead now. Had many facets, but now he'll go down in history as just another damn Chinese warlord who didn't make the grade. It is remarkable, love," he said, looking at Nell for the first time, "how much money you can make shoveling back the tide. In the end you need to get out while the getting is good. Not very honourable, I suppose, but then, there is no honour among consultants.


So much of the discourse about this movie was in the meta-sense of "big, vaguely selfaware action rom-com starring two of the leads from Barbenheimer that is critically well-received but a box-office bomb — whither Hollywood?!" I think you can safely ignore that kind of pablum; this movie is neither good nor essential enough to warrant a wave of discourse, which is not to say that it's bad. It's not a Very Good movie; it's a very Good movie — in the lineage of The Nice Guys or The Other Guys (both Guys movies themselves), winking and pleasant and charming and a little bit overlong.

There absolutely should be more of these kinds of films, if for no other reason than to remind us that part of the value proposition of top-tier movie stars is that they can elevate something a little bit further past its script-borne shackles. (And Gosling is terrific in this, make no bones about it.) But it is not some sort of deep, industrial crime that this is not more widely beloved.


When I wrote Your job is to produce value, I got a few responses that could be summed up as something along the lines of:

Telling developers to get better at reading and writing and problem solving is sort of like telling them to get better at writing fewer bugs: it might be true, but it's anodyne and unactionable.

First off: this is not true, and if you think this way (that, say, communication is some sort of inherent skill and not a thing that improves with practice and study) you should probably try to carve out daily rituals of blogging, reading, and UX research.

But! I am sympathetic to the argument that there are more decisions and options an engineer has to make in their career than simply being customer-, finance-, and experience-focused. Knowledge accretes, and while a certain radical generalism — no stacks, no sectors — is probably the best overall meta for a young engineer the reality is that you will have to make choices about which companies/organizations/teams/languages to spend time on, and those choices have marginal consequences: all other things equal, someone who joined a web3 startup in 2020 or an Angular shop in 2018 probably has marginally worse prospects than someone who got into GIS work or Swift right as they were taking off.

(I use the word "marginal" there intentionally: the industry or technical stack you land in is far less important to your career than anything else.)

This belies the question: assuming that you don't have oracular vision, what kind of opportunities (at the company level, at the project level) are the right ones to pursue?

I have two answers that I think overlap a good deal:

  1. Haunted forests. In the linked essay, John talks about this metaphor within the context of SRE, but I think its true at a broader, more conceptual level: the prize for tackling domains and codebases that terrify others is knowledge, esteem, and many battle scars.
  2. Lindy tech. In the grand catalog of infrastructure required to run the modern world, the most powerful and most useful — DNS, SMTP, relational databases — tend to be old.

I say these two things overlap because folks often use the terminology of the former to describe the latter. "Don't roll your own auth"; "DNS is an eldritch horror"; "never try and send your own emails"; it's tempting to buy into these truisms, but the twelve months you spend really understanding how DNS works at a primordial level is going to have more long-term value than the twelve months you spend on GraphQL or whatever.

(All of this is true at an organizational level, too. Institutional knowledge decays over many axes; one way to stave off the inexorable decline is to invest in meaningful, durable substrates.)


It's fascinating to see that this is a Richard Linklater (of Everybody Wants Some!! and Before Sunrise) fame, as this feels in many ways so much more like a Lord & Miller production (or, more charitably, a lesser Coen work).

And, indeed, you can see Linklater take his foot off the gas and lean a bit into the "ehh, this is a Netflix paycheck" of it all: the hackneyed philosophy lectures, the bizarre suspension of disbelief required for most of the sting operations. But it's also a deeply entertaining film: the conceit is immediately delightful and interesting, Glen Powell acts his ass off, and the runtime knows that there's no room (or need) for unnecessary padding (unlike, say, The Fall Guy).

I'd argue that this is not a particularly good Linklater movie — I think he is most interesting when he is using cinema to express his feeling about the beauty and depth of seemingly-anodyne humanity, and this is him ignoring all that and deciding that it would be fun to make a rom-com. But it is a deeply good Netflix movie, and a perfect answer for "what's a fun, perfectly-delivered way to spend two hours?"


This quote from Peter Drucker, via @zetalyrae resonates a lot:

Write a report may, for instance, require six or eight hours, at least for the first draft. It is pointless to give seven hours to the task by spending fifteen minutes twice a day for three weeks. All one has at the end is blank paper with some doodles on it. But if one can lock the door, disconnect the telephone, and sit down to wrestle with the report for five or six hours without interruption, one has a good chance to come up with what I call a “zero draft”—the one before the first draft. From then on, one can indeed work in fairly small installments, can rewrite, correct and edit section by section, paragraph by paragraph, sentence by sentence.

This rhymes (but not does quite exactly overlap) with an oft-quoted section of The Mythical Man Month:

In most projects, the first system built is barely usable....Hence plan to throw one away; you will, anyhow.

(Notably, Brooks recants that suggestion in later editions of the book, as he says it "assumes the waterfall model of software construction.")

The process of "zero drafting" in my work generally looks something like this:

  1. I am tasked with a hairy problem: not an intractable one, but one that feels vague and scary and without an obvious immediate plan of attack or path to resolution.
  2. I carve out an afternoon to attack the problem, where the goal is not to solve the problem but to have emerged victorious in my understanding of the problem and with a WIP PR with no plans to merge. [1] The WIP PR can have broken tests and bugs and poor documentation, but it has the broad strokes of a path forward.
  3. I then take time to carve out the obvious and safe things to extract from the WIP PR — inert database changes, necessary refactors, et cetera — and submit net-new PRs for those.
  4. Suddenly, all that is remaining is the critical path, and we can close the WIP PR in favor of something cleaner.
  5. Lo, the problem, it is solved.

The hardest part of this entire thing is the "carving out an afternoon" bit: good weeks tend to look like ones where I have three entire afternoons, and I'm a sucker for snacking.


  1. This kind of process happens for non-engineering work, too, but I digress. ↩︎


It took my brother two years to watch this from start to finish, and it reminds me more than anything of trundling through The Romance of the Three Kingdoms as a kid — a parallel that I'm sure I'm being unoriginal in drawing, but the mixture of long-form historiography, hagiography, fact and fiction, and faint sense of ennui is hard to ignore.

LotGH is a commitment. It is rarely "fun" in the way I think I would expect a traditional space opera to be fun; perhaps more pointedly, the show uses the "space" part of "space opera" hardly at all except to feint at the size and sweep of the events being depicted, and while hours are spent on space battles the tactics are almost purely naval in nature.

And, unlike Romance of the Three Kingdoms, Legend of the Galactic Heroes is not that interested in action scenes.

What the show is interested in is everything else: the nature of history, the foibles of man, the cosmic cruelty of war, the benefits and drawbacks of fascism, the benefits and drawbacks of democracy, the nuances of supply chain mechanics, the lives and deaths of heroes, the curse of memory, the light of peace.

There are parts of LotGH that do not work, or (phrased slightly differently) detract from the core of its gestalt: Terraism (a goofy plot device that serves for little else than a prevention of narrative detente), female characters who exist almost entirely to be married to high admirals. But these are quibbles, little nits to pick out of a rich and nuanced tapestry of how humanity never really changes.

Watch this show: it will be slow, and the first dozen eps are truly terribly animated, but it rewards your patience.

Highlights

Before freedom and equality, could we have bread and meat?

Having a history differentiates humans from all other living species.

Too many things have happened already / and there is too much already for us to do.

Good people, remarkable people are killed meaninglessly. That’s war, and that’s terrorism. The sin of wars and terrorism, in the end, comes down to that.

Politics always takes vengeance on those who belittle it.

A sword has no reason to exist but as a sword.


I wrote a bit in Everybody's in L.A. about the constraint of evaluating the merit of something that's in conversation with a genre you don't really care for in the first place; I don't care much for late night shows, and I care even less for kaiju movies, even with my knowledge of "Godzilla is a metaphor for the destruction and threat wrought by nuclear war" and the litany of thinkpieces therein.

The majority of the hay made about Godzilla Minus One is about two things:

  1. It's scant $15m budget;
  2. How well it works as a postwar Japan film even without the Godzilla stuff.

I can certainly agree with the former — the scale and craft of the effects were very well done — and the latter is where things lose me. The protagonist is certainly more interesting than your typical disaster film's, and the extended metaphor of survivor's guilt has more emotional resonance than more films in this genre — but come on, guys, this is still a Godzilla film, and the credulity required therein (let alone the paper-mache thinness of every other character in the script) means that I can like this relative to the Cloverfield Projects of the world, but it's still not exactly going down in my history books.


Previous page · Next page

Lightning bolt
About the author

I'm Justin Duke — a software engineer, writer, and founder. I currently work as the CEO of Buttondown, the best way to start and grow your newsletter, and as a partner at Third South Capital.

Lightning bolt
Greatest hits

Lightning bolt
Elsewhere

Lightning bolt
Don't miss the next essay

Get a monthly roundup of everything I've written: no ads, no nonsense.