Today I Learned

Most Recently

2026-08-06
I'm Switching My Phone From Android to Linux

I'm not there yet but it's coming.

2026-08-03
If You Build It, They Will Come

Can confirm, this is absolutely the way. Run events for communities you're involved with over years. It's totally worth it for all the social benefits it bestows even if it means donating half your PTO or some of your hobby money to make it happen.

2026-07-31
Lecture Friday: A CRDT Primer: Defanging Order Theory

In case you missed CRDTs when they got really popular a few years ago, this is a decent introduction.

Abstract algebra strikes again. You should learn it. If you want a simpler introduction, the talk Add ALL The Things: Abstract Algebra Meets Analytics is more approachable. In this talk you'll get exposure to the importance of lattice spaces, and specifically join lattices. These are useful not just because their symmetry is pleasing, but because they provide a tool to help you visualize all permutations of operations on the space. This lets you check your design for missed associativity, commutativity, and transitivity.

I'm not sure where I stand on CRDTs. If you're stuck with the space and time performance penalties they impose, it should be a problem where there really isn't an alternative. Very few applications really have to be offline-first. With most people limited to phones, there's not much call for P2P applications these days since their owners (Apple and Google) prohibit such uses. There's only so many people living on boats or battlefields.

I struggle to find a situation where you need disconnected concurrent editing of a shared data structure that merges without conflicts. Even in documents, who wants to write a bunch of stuff in a section someone else deleted, only for it to disappear when they come online? The section was deleted, that's the correct merge algebraically. Still doesn't seem right to the user.

So I'd suggest learning the algebra. Apply it in designing your systems. Don't think of using CRDTs as adding a feature. Think of them as a set of protocol properties, like idempotency, for solving distribution problems. That's why I think it's worth watching this talk. Understand how this sort of thing works so you can implement it if/when it makes sense in your work.

2026-07-24
Lecture Friday: Hardware, Software and Heuristics

I mean, not a novel insight on my part, but Feynman really is an amazing explainer. This was so much fun to listen to. He's completely right too. Everything reduced to something so easy I think anyone could comprehend it. It's also great to dig back into the fundamentals. Always keep yourself in them. They often help you think novelly about something others are taking for granted.

I love that he stopped at the transistor and my brain just kept going. A transistor works because a voltage at the gate creates an electric field that opens or closes a channel for electrons. And an electric field works because charge creates a field that exerts force on other charges. And that works because of $U (1)$ gauge symmetry, which requires the field as the price for local phase invariance.

The problem of pattern recognition is interesting. It's true that in the last 50 years since this talk we've made significant strides in solving such problems. We're at the point we have enough computing power we can work with natural language to a really impressive degree. I'm curious what pattern recognition problems still evade us at this point. The big one that comes to mind is in reducing the amount of input data required. Right now we need an enormous amount of training data for these models relative to what a human seems to need. Reinforcement learning always seems promising, but existing techniques are so fragile and slow compared to supervised learning.

It's at least refreshing to see people freaking out about computers taking jobs a half a century ago and watching someone else try and explain to them they're asking wrong question. I find it so exhausting being asked if the word guesser will turn us all into paperclips. Same for the question about if the computer will become Big Brother. I mean, a Manhattan Project contributor is maybe not your best steward of ethical philosophy. That said, humans are adaptive advisories, so while more surveillance is happening than ever before, it still hasn't stopped dissent or régime change. We're just better now at distracting ourselves to death.

2026-07-17
Lecture Friday: The Internet With a Human Face

We're still trying to fix the mess we created with the car over the last century. We haven't even begun to undo the mess we've made with the smartphone. Let's give chatbots to everyone! To be clear, these technologies can be great when used in their ideal niche, but it's the forced mass adoption that unlocks chronic problems. Monied interests bending the fabric of society to perpetuate them. Large monocultures are inherently fragile. When faults occur the shock ripples system-wide, with no alternatives to absorb it.

The comments about how clueless Americans are about the rule of law being like an infallible law of physics is funny in hindsight now they have an active paramilitary kidnapping their neighbours, run concentration camps across the country, and are building out one of the largest dragnet surveillance networks in history.

With the AI bubble, maybe we're at the end of investor story time? We've got every investor locked into a race for a commodity based on the story that computers will soon become god. Sounds like we're at the end of a JRPG. I'd speculate it's the end of the road for tech VCs but it looks like they're trying to unload those assets onto pensions and retail investors.

Decentralization is the right goal, but it will require regulation to scale. Left unchecked, markets naturally concentrate power. Any initial advantage lets a player absorb competitors, compound their strength, and repeat. If we want to stop monopolies from swallowing our institutions, we need to act soon, before policy-making and even enforcement are fully outsourced.

That comment about recognizing a problem, and agreeing on the problem, is absolutely the first most important step. Without consensus that a problem exists, any attempt to fix it is doomed to derail. I have seen this fail too many times. Everyone must agree on the diagnosis and be willing to act. This will be difficult. Powerful interests profit from the status quo and will actively resist recognition, let alone solutions. The decades-long fights over the greenhouse effect and tobacco prove how hard it is. Today, manufacturers add a battery to rebrand cigarettes as blueberry vapes, while bookies run apps or games to call it a prediction market or loot boxes rather than illegal gambling. As long as exploitation is profitable, these battles will continue.

2026-07-10
Lecture Friday: Sorting Algorithms: Speed Is Found In The Minds of People

I've gone on record before to say, stop teaching sorting algorithms. They're not interesting. Teaching early Computer Science students sorting algorithms is a form of ritualistic hazing at this point. Teach them convex hulls instead. Full of graphics and tons of obvious practical applications to the beginner or interdisciplinary studier. However, this is a great talk. So watch it anyway.

The big reason is that this is what real performance looks like. This isn't some theoretical big-O notation view of the world. This is how real computers work and how they really don't align with that simple model everyone was taught.

$(C (n) M (n) k D (n)) n$

2026-07-03
Lecture Friday: Secret History of Silicon Valley

It always pays to learn your history. Lots of potential lessons.

2026-06-30
Worldly Wisdom by Charlie Munger

Lots of interesting nuggets in this. Stuff I already knew (like Coka-Cola isn't a beverage company, they're a psychology company), and stuff worth taking away (it pays to be #1, #2, or out; and in human affairs what wins are incentives). But mostly a lot of just admitting the world is a magical place full of wild contradictions with no sure way to tell which is applicable to some new context if you have to put your money where your mouth is.

I really like the idea of stealing the big ideas from a variety of fields and working hard at layering them into a lattice of ideas you can leverage. That's actually what lead me to these talks. Probably wouldn't have read it otherwise. It's what I've been trying to do for at least the last decade. Obviously I'm not a securities trader like Munger, but it still proves valuable in software development.

He's also right about decision trees, though these days you'd probably want at least a random forest. The bigger thing is statistics and how it's become too big to ignore. Learning how to properly build (or train as the kids call it) models on data, especially the instinct to collect such data is now a core skill you should know. You'll have a hard time keeping up with anyone who knows how to routinely do this if you remain math illiterate. Statistics especially, unlike geometry, is a branch of math our feeble human brains are really bad at intuiting. It's why there are so many gambling startups right now. It pays to run the house.

2026-06-29
Fintech Engineering Handbook

A decent overview of concepts from the financial software industry. I mean, clearly written from the point of view of someone working with cryptocurrencies and payment processing, but not in a way that makes it a bad source of information. Honestly some great intermediate topics in there like some of the most common account types, red flags to auditors, and a decent list of some of the major payment networks if you want to dig deeper. Also a bunch of wise words about how trying to integrate against anyone else handling money is a crazy train you better be ready to handle (including some decent strategies).

If you still haven't learned that what a human sees and what a computer stores not only can be different, but often should be, money's a good introductory lesson. Only use floating point for measures, never counts. That is, numbers that have a degree of precision to them. Think like measuring a distance. Is it exactly 3 units, or is it 3.0000...something? They are not to be trusted for exact counts. Just like you don't have 2.00 kids, you don't have $2.00. You have 200 cents and their owners know each by name.

On the testing angle, I'll say I'm at the point that unit tests are dead to me. If you're not fuzzing your code, your tests are performative.

2026-06-26
Lecture Friday: Efficiency with Algorithms, Performance with Data Structures

Performance continues to dominate (duh). Why do you care about performance today? AI? No, performance is always important. Blame it on whatever's hot if it helps. Users care about performance because time is money for you and your customers. It's all about convenience. Customers love convenience. Too much if we're being honest. Cost equal, they'll choose the more convenient option every time. Many will choose it even if it costs more if you market it using time-loss aversion. Better still, fast also wins on the cost front. Fast software means you can run more of it on less hardware. Less hardware, less power, lower COGS. But wait, there's more! Faster software encourages doing more with it. If it takes a couple milliseconds to do something, I can do a whole heck of a lot of it in a few minutes. More buy-in, more self-service, more use cases unlocked.

I will emphasise that the minor efficiency wasting patterns stacking up is the dominant problem. It's not slow spots, not a cutting edge algorithm you could have used. It's everyone, everywhere, doing the same slow version out of habit when a faster version exists. It's the problem because fixing it is fighting entropy. As your company scales, the problem gets worse and worse. Fifty nanos wasted on every instance of a given operation, implemented in thousands of places, executed millions of times for large datasets (a.k.a. your most valuable customers). The requirements to fix it is measured in dev years.

Some languages do have syntactic problems that cause performance issues. Other languages have non-optimizing compilers or interpreters. Many have standard libraries with lots of suboptimal functions and data structures. But for the most part, the dominant factor in the performance reputation of a language is cultural, not intrinsic. It's created through a combination of the tools, libraries, and references the community contributes to and learns from. What they consider "idiomatic" or "best practice" code. It's why people think React is slow and Rust is fast even though tons of slow Rust code has been written and plenty of fast React apps exist. It's the people, not the tool. Learn how to use your tools better. Advocate for better tool use.

2026-06-23
Time Management for Anarchists

My only secret to productivity: offload everything from my brain so it doesn't have to remember anything. Use habits, notes, calendars, lists, creative constraints, deadlines. Externalize the work your brain is bad at.

I use paper for most of it. It's on my desk and fridge. I can't forget about it that way. Paper lets me spread things out, reorder them, stack them in piles. This trivially encoding more information through spatial memory than any file system. No software needed. I have a digital calendar, but every month I fill out a large paper one that sits on my fridge. I cross off days. I see everything at a glance. I track habits and chores.

The same logic applies to meetings. I now create notes ahead of time so I never forget to bring up the topics I want to cover in my brief window with someone. Think of something else to discuss? Add it to their card. Each note has the person's name and the things I want to talk about. If we don't get to something, it carries over. No brain power required.

I keep notes for projects, for ideas, inline in my code for things I want to improve later. I no longer bother remembering any of it. I write it down and review it as a habit—usually at the start and end of each day. That's when I prune. The secret to a todo list is copying it fresh every morning and throwing away yesterday's. Do not keep things around. You either do them or stop copying them. A backlog is a lie you tell yourself to avoid the hard work of saying no.

I apply the same system to cooking. I love cooking but hate deciding what to make. It takes me thirty minutes to brainstorm meals whether I'm picking one or a dozen so I build a list. Meal after meal goes on it until I have enough for a grocery run. I fill the back with ingredients to buy and cross them off in the store. The remaining list becomes my menu until it's empty. What's for dinner? Check what's left. It's easy to pick when there are two or three options. I mark meals as short or long depending on perishables so that fresh vegetables go first, then the dishes that keep. I shop roughly once a month.

Deadlines do more than force delivery. They create a rhythm of tension and release. As one approaches, I go into crunch: cutting scope, accepting tradeoffs, shipping. Afterward I relax, unwind, think creatively again. Too many deadlines too close together is death, but a good cadence ebbs and flows like the tides.

I've kept a ledger of all my earnings and expenses for over a decade. I started it in college after discovering the ledger CLI. The file is 18,000 lines now, managed with a text editor and a handful of scripts I wrote myself. It taught me double-entry accounting. More importantly, it gave me clarity. I know exactly how much I need to retire. I know how long my savings last if I quit or get fired tomorrow. Someone once called that kind of cushion "fuck you money" — as in, "fuck you, I don't need to put up with this." And knowing I have that option really reframes my relationship to work. I don't need the job. I choose to work here.

2026-06-19
Lecture Friday: Magic: the Gathering: Twenty Years, Twenty Lessons Learned

These lessons are about design, not just game design. They're fundamental to human nature. Consider these in the context of your work. You'd be surprised just how much they hold up in other fields. Swap fun for value, swap audience for customers. It's all the same big interconnected lesson about making things for other people.

Fighting against human nature is a losing battle.
Aesthetics matter.
Resonance is important.
Make use of piggybacking.
Don't confuse "interesting" with "fun".
Understand what emotion your game is trying to evoke.
Allow the player the ability to make the game personal.
The details are where the players fall in love with your game.
Allow your players to have a sense of ownership.
Leave room for the player to explore.
If everyone likes your game, but no one loves it, it will fail.
Don't design to prove you can do something.
Make the fun part also the correct strategy to win.
Don't be afraid to be blunt.
Design the component for the audience it's intended for.
Be more afraid of boring your players than challenging them.
You don't have to change much to change everything.
Restrictions breed creativity.
Your audience is good at recognizing problems and bad at solving them.
All the lessons connect.

Side note to remember from advertising: knowledge → familiarity → preference → quality.