Buttondown has a new Twitter handle, which also marks my first (and, if I were to bet on it, last) foray into social media account purchasing.
I had had @buttondownemail
for a while and it was, you know, fine. The success or failure of an enterprise is not determined by the concision of its social media identifier, you know? But, because I am foolish, I wanted @buttondown
, and had a lingering to-do item to try and track down the owner.
The account appeared to be in use, but it was hard to tell: there was a name (“D. Laackeman”), a location (“Vermont”), and a handful of followers and following behind a protected account. I did some sleuthing, found someone who matched the profile on LinkedIn, and slid into their proverbial DMs.
We agreed on a price of $1,000, which took the form of a tax-deductible donation to the charity of the seller’s choice. This was pretty much ideal: I get a bit of aloe on the sting of spending a thousand dollars on a vanity handle.
The sticker price reminded me of another incident of foolish spending that I didn’t have the immediate acuity to recognize as such:
Spending two thousand dollars on various email enrichment APIs over the course of 2018 was…rougher. That was me spending money because I didn’t think about what users actually wanted or about unit economics. At least with a Twitter handle, I can be a little more honest with myself about how truly vacuous the whole thing is.
I got to spend my morning dealing with Heroku scale-ups. A couple miscellaneous notes:
I spent my morning reading a former colleague’s paean to performance:
I’ve really come to appreciate that performance isn’t just some property of a tool independent from its functionality or its feature set. Performance — in particular, being notably fast — is a feature in and of its own right, which fundamentally alters how a tool is used and perceived.
One of the recurring pieces of feedback and appreciation we got from Stripe engineers following the Sorbet rollout was how fast the tool was. In a world of slow tooling1 developers genuinely appreciated a tool that felt fast and responsive.
I think the value of performance is sometimes well-understood intellectually — many engineers know of and talk about the perceptual thresholds for response time or the impact of latency on conversion rates — but it’s rarely appreciated on a really visceral level, and also is often given lip service more so than real investment. It feels popular to bemoan slow software these days, and yet it also feels rare that a team is doing something about it — our tools still keep getting slower. My experiences lead me to the strong belief that while our tools do make it increasingly hard to write fast software, it’s very much still possible, and very much still worth it.
Buttondown is....not quite fast enough. It’s faster than a lot of other similar tools, but there are operations that simply take too much wall-clock time or are otherwise flaky in performance. I think about sending emails and validating subscribers as the two performance bottlenecks and they are both getting worse, not better!
The first step is, like I said, having actual metrics around this so I can track the change over time, but when given the choice between instrumentation or polish I tend to default towards the latter. There are some easy ways where I’m pinning performance, like unit tests making sure certain operations don’t exceed a certain database load:
def test_list_num_queries(self): FakeData.subscribers(10, newsletter=self.newsletter) with self.assertNumQueries(5): self.client.get(self.url)
But this is hardly sufficient. Time to, amongst other things, set performance budgets.