It’s Saturday evening, it’s still bright and sunny and warm outside. I mowed the lawn, wrote some code, grilled some burgers, reverted some other code, ate too much ice cream, had a beer, and I don’t think I’ve ever written this newsletter on a Saturday evening.
I’ll be in San Francisco in the first two weeks of August. One week of work, one week off. I’m also going to give a talk at the AI Dev Tools Night and if you’re around: say hi!
My favorite this week: matklad’s Inverse Triangle Inequality. Small commits, small refactors, small releases. Yes, yes, yes.
matklad’s post links to this grayon2 post: The Not Rocket Science Rule Of Software Engineering, which says to “automatically maintain a repository of code that always passes all the tests”.
Go and get an OpenAI or Anthropic API key and open the Infinite Monkey. I won’t spoil it and will only quote a single sentence: “Chat with an LLM to control an emulated classic Mac.” You’ll love it.
This is what blogging and writing online is about, isn’t it: The First Time I Was Almost Fired From Apple. I remember a time in my life when this sounded alien: “It was frankly a thing I liked about working for Apple in those days. The engineers were the one’s driving the ship. As I said, I wrote an HSV picker because it was, I thought, a more intuitive color space for artists. I wrote the HTML color picker because of the advent of the web. And I wrote the crayon picker because it seemed to me to be the kind of thing Apple was all about: HSL, RGB — these were kind of nerdy color spaces — a box of crayons is how the rest of us picked colors. And it turned out, to my surprise, Apple shipped all the color pickers. No marketing or design person ever asked for them. But we, engineers, were not only programmers, we were also users and often had an intuitive sense of what other Macintosh users wanted. We knew what we wanted anyway. I was creating the things I would have wanted.” Now it doesn’t anymore.
We need more posts like this one: systemd has been a complete, utter, unmitigated success.
Separate bullet item to tell you to browse through the blog to which the previous post belongs. Start here, with Same Stop: “In fact right after retirement there was a sense of relief that I would never again have to step through code trying to determine why a dispatch to a background thread never completed. No longer would I have to worry about completely screwing up the project repo because of my misadventures with git. The respite from programming though lasted maybe about four months after retiring.”
“Kimi K2 is a state-of-the-art mixture-of-experts (MoE) language model with 32 billion activated parameters and 1 trillion total parameters.” — 1 trillion. I tried it, threw some code at it, saw the response, went to Slack and wrote “holy shit.” Not necessarily repeatable, but hey.
How fast is it really? This isn’t — sadly — as much of a deep dive as it could’ve been, but while giving an overview of what’s involved when measuring latency in high-frequency trading systems, it still manages to nerd-snipe: “If we solely wanted to measure the latency of the system, we could tag each outbound message with the market data event sequence number, then, for each order, you can grab the NIC hardware timestamp tagged for the inbound market data event, and subtract it from the NIC hardware timestamp for the outbound order.”
Merlin Mann recently pushed some updates to his Wisdom Project. As always, it’s lovely: “Never brag about your weather. You had no agency in creating it and deserve no credit for living in it. […] Sometimes we make things to teach, but often we make things to learn. […] When you’re trying to help someone, focus on the help that the person needs rather than the help you feel like giving them.”
Zed launched a landing page for upcoming Windows support: windowswen.com. Amazing stuff.
This post here, titled “Reflections on 2 years of CPython’s JIT Compiler: The good, the bad, the ugly”, along with this comment thread is very interesting. Nearly 3 years of work on the JIT compiler and the post contains this: “CPython 3.13’s JIT ranges from slower to the interpreter to roughly equivalent to the interpreter. Calling a spade a spade: CPython 3.13’s JIT is slow. It hurts me to say this considering I work on it, but I don’t want to sugarcoat my words here.”
I really, really thought I’d turn my nose up at this, the Red Hat Technical Writing Style Guide. The legal notice, the preface, the 3-level-deep numbering — it made me think of the German notary system. But! Well, I ended up really liking this. There’s a lot of very good stuff in there. Most notably: examples, examples, examples.
“It’s one thing to stand off to the side and critique the way a company is structured and the decisions leaders make about compensation, structure, hiring/firing, etc. But creation is harder than critique (one of my favorite Jeff Gray quotes) — so, so, so much harder. And reality resists easy answers. Being an adult, to me, has meant making peace with a multiplicity of narratives. The world I was born into had a coherent story and a set of ideals that worked really well for a lot of people, but it was killing me. Not every system works for every person, and that’s okay. That’s life. Startups aren’t for everyone, either.”
Billionaire math, by apenwarr. Too wide and deep for me to come up with a matching paragraph. Go read it. (But, I have to admit, this made me smile a weird smile: “By the numbers, you’re probably a software developer. So you’re probably in the top 1-2% of wage earners in your country, and even better globally.” Except when you’re in Europe, it should’ve included.)
Randomly ended up re-reading this post and remembering how much I liked it the first time: headline driven development. Here, the first paragraph, packing a punch: “Here is a simple process for shipping software projects that works. First, decompose the project into a stream1 of headlines. Then pick an aggressive date to ship the first headline and work like hell to meet that date. Have everyone work only on one headline at a time– the upcoming one. Ignore everything else. Don’t work on anything that doesn’t help you ship the headline. Once the headline is shipped, switch to the next headline in the stream and repeat. That’s all, you can fire your agile consultant.”
