The joy of figuring out how software works may be lost

This was beautiful to read - the joy of understanding how something works, reverse engineering a piece of software or debugging something for hours and the joy of "figuring it out" is something that might become a lost art in the decades to come.

I feel this will cause us to spend a lot more time introspecting - what do we really want, dig into the motivations behind our want and the guardrails around what are we ok with.

unix.foo/posts/last-people-who-know-how-it-works

The Last People Who Know How It Works · unix.foounix.foo
  • Coding agents

Keep reading

Coding agents

PostHog's 70x faster SQL parser built with Claude Code

Robbie Coomber from PostHog rewrote PostHog's SQL parser using multiple long-running Claude Code sessions in parallel. The result was 16K lines of "hand"-rolled parser code, 5K lines of tooling, a few more K of tests, and a ~70x speed up! Thats awesome. There really is no excuse to not ask Claude or Codex to optimize your codebase. Of course it requires providing the right evals and harness so that it has a way to measure correctness in an objective way. Also I love that they have a formal declarative grammar for the parser using ANTLR .g4 format. Read more here: posthog.com/blog/sql-parser

Software architecture

Microsoft pg_durable and keeping everything in the database

Microsoft open sources pg_durable - this allows durable task execution within PostgreSQL. I personally really like the pattern of keeping everything within the database and avoid external queues, multiple databases to manage state, locks etc. Every additional architecture module introduces complexity that might not be needed. In most applications if you keep everything within the DB, it makes each individual flow fast, clean, contained. And re: scaling, just scale vertically and then shard as needed. That works for most b2b apps. github.com/microsoft/pg_durable