This time, as a little intro, a reading recommendation: the first half of How Innovation Works by Matt Ridley. It’s a relatively short book, quick to read, and doesn’t contain any revelatory insights you can’t find anywhere else. But that first half — that’s what I recommend you read. I read it a year ago and constantly think of it.
In that first half, Ridley shows how innovation in different areas and industries — energy, transport, public health, communications, and so on — actually happened versus how we imagine it did. Apparently never in the history of innovation did a person scream “I got it!” upon discovering something new and the world replied with a loud “hell yes!”
When you read that first half, you see how unpredictable breakthroughs are, how many experts made completely wrong predictions, and how often truly important innovations were initially dismissed as boring or irrelevant.
When you finish it, you’ll have a new voice in your head, one that says “wait a second”, whenever something new happens or someone makes a prediction about what will happen. I find it very useful in times like these.
As someone who’s read quite a few John le Carré novels and, while watching movies, often says to his wife “to be a spy! imagine!”, this was by far my favorite piece of news this week: Rippling sued Deel after setting up a honey trap for one of their employees, whom they suspected of being a spy for Deel, and successfully caught him. The honey trap? Rippling mentioned a “defectors” Slack channel in a letter to Deel. The catch? Rippling went through the Slack audit logs to find one person — the spy — who searched for that channel name ten times within hours of the channel name reaching Deel. I love it. I didn’t know you could write lawsuites like that: “97. Deel-through D.S.—took the bait. Within hours of Rippling sending the letter referencing the #d-defectors channel-again, a channel that existed only as bait for Deel, and one which D.S. could not have known existed absent a connection between himself and Deel —D.S. ran the following searches in Slack” Tinker, Tailor, Rippling, Deel.
Benedict Evans on Apple’s AI features being delayed: “I’m unsure how much of a disaster it is for Apple to ship what it described last summer in 2026 or 2027, and in the meantime push out a flow of more achievable individual features. On one hand, it’s not as though anyone else has what Apple described working yet, even Google. On the other, a year is a long time given the speed of AI progress right now” The line that I saved, though, is this one: "Yes, Apple could maybe make better seats than Collins Aerospace, but that’s not what it means to run an airline. Where can Apple change the fundamental questions?"
Will Larson with career advice for 2025: “Sitting out this transition, when we are relearning how to develop software, feels like a high risk proposition. Your well-honed skills in team development are already devalued today relative to three years ago, and now your other skills are at risk of being devalued as well.”
Caspar Wylie knew that I love ASCII diagrams and sent me a link to his web-based “ASCII diagram builder” called CASCII. It’s lovely! I’ve been a happy Monodraw user for 9 years now, but CASCII being on the web makes it very special.
This post with “some thoughts and predications” on vibe coding contains this angle from which to look at what’s happening: “If you compare to prior content creation trends, you could argue that the photos that people post online are a lot worse than what professional photographers post. Same with YouTube videos and what a filmmaker would create. But it doesn’t matter, simply because the sheer quantity of content […] make social media dominant. The same could be said of software.” What if what happened to photography will happen to software?
“Everyone wants the secret, the key, the roadmap to the primrose path that leads to El Dorado: the magical low-risk, high-return investment that can double your money in no time.”
“But the fact of the matter is: if you wanna be good, you really don’t have a lot of choices. ‘Cause it takes what it takes.”
All of the commentary on Apple in the last two weeks — Gruber’s two posts, Benedict Evans’ above — made me look up Scott Forstall on Wikipedia. He’s the former Apple SVP who was (made?) responsible for the Apple Maps launch and when Maps was criticized for having too many errors and “when Apple issued a formal apology for the errors in Maps, Forstall refused to sign it. Under long-standing practice at Apple, Forstall was the ‘directly responsible individual’ for Maps, and his refusal to sign the apology convinced Cook that Forstall had to go.” I vaguely remembered that. But then Wikipedia kept surprising me. First wow: Forstall is now a Tony Award-winning Broadway producer. Second wow: did you know that in iOS 6 (which Forstall was responsible for) “the clock app used a design based on the trademarked Swiss railway clock, which Apple had failed to license, forcing Apple to pay Swiss railways a reported $21 million in compensation”? I didn’t and thought: what’s so special about the Swiss railway clock? And then read that article and — Maps this, Broadway that — came to the biggest wow-moment of this particular Wikipedia ride: “The station clocks in Switzerland are synchronised by receiving an electrical impulse from a central master clock at each full minute, advancing the minute hand by one minute. The second hand is driven by an electrical motor independent of the master clock. It takes only about 58.5 seconds to circle the face; then the hand pauses briefly at the top of the clock.” I don’t know what I thought, but that’s not how I imagined station clocks to work.
This collection of AI blindspots is remarkably good. Take this one, Culture Eats Strategy: “If the LLM is consistently doing things you don’t like, you need to change its culture: you need to put it in a different part of the latent space.” Yes! Nearly everything changed for me once I understood how attention works in transformers and how, by writing a prompt, I’m navigating the latent space. The hard part is that this collection of AI blindspots will probably only make sense to you if you experienced them yourself. My advice? Go out there and throw everything you have at these models. Try this strategy, try that one, put this in context first, then the other way around. You need to build up an intuition and once you have it you realize that working with these models is not a coin toss, but that you can navigate the latent space, even if the road is wobbly.
Bill Hader on feedback: “When people give you notes on something, when they tell you it's wrong, they're usually right. When they tell you how to fix it, they're wrong.”
In case you missed it: Pierre, a new code host, is now open to everyone. I’m obsessed with their landing page. This week, Jacob put out this video. I’m telling you: you could pay a marketing firm high six-figures and they would desparately try to make a video like this and fail.
stevey wrote a very stevey post on the Sourcegraph blog that, underneath the jokes and predictions, contains some very subtle yet important points that are constantly lost in discussions not just around AI but tooling and programming in general. Right there, fourth paragraph: “How closely you choose to pay attention to the AI's work depends solely on the problem at hand. For production, you pay attention; for prototypes, you chill.” The context in which we build software matters.
I think this comment on stevey’s post is spot-on: “I have to think a lot of people just haven’t tried it in its best form. No, not a local model on your MacBook. No, not the web interface on the free plan. Go lay down $300 into API credits, spend a weekend (or maybe two) fully setting up aider, really give it a shot.” I don’t think you need $300. Make it $50. But if you’ve only ever tried ChatGPT two years ago, I can’t have a discussion with you about AI and programming in the same way I can’t have discussion about laptops and touchpads with someone who’s never held and tried a MacBook.
C.S. Lewis writing in 1959 to “Thomasine, a child in seventh grade”: “Write about what really interests you, whether it is real things or imaginary things, and nothing else. (Notice this means that if you are interested only in writing you will never be a writer, because you will have nothing to write about …)” As a teenager I wanted to become a writer until I read somewhere that writing is a secondary skill: you need to be good or interested in something else, so you can then write about it.
Boz on How Not To Disagree: “In this scenario, many leaders sell out their management and rally the team. They say management sucks, but don’t worry, we will make progress in spite of them. This approach is staggeringly effective. Until it isn’t.”
This blog post by Anthropic is confusing and the name of what it’s about — the “think” tool — doesn’t help. My two sentence explanation: you say “here, think into this” and you hold open
/dev/nulland it thinks into it and that makes it better. It’s like saying to someone “make a list of pros and cons on a whiteboard” to improve their decision making process. My five word summary: holy shit, this is wild.Paul Ford’s “What is code?” article is now 10 years old and I still think of it regularly. Not only because of the writing (very good), and not only because of the design (it’s something you won’t forget), but also because: Bloomberg published it like this!
Haven’t come across this Paul Graham essay from 2012 before: Schlep Blindness. Schlep “means a tedious, unpleasant task. No one likes schleps, but hackers especially dislike them. Most hackers who start startups wish they could do it by just writing some clever software, putting it on a server somewhere, and watching the money roll in—without ever having to talk to users, or negotiate with other companies, or deal with other people's broken code. Maybe that's possible, but I haven't seen it.” It resonated right after those first two paragraphs. Made me wonder how Schlep blindness/aversion would map to my two types of engineers.
One of the most impressive things I’ve ever seen a company build and gift.
Good pairing if you enjoy thinking about consciousness: Living Things Are Not Machines (Also, They Totally Are) and Joscha Bach in the five minutes following this timestamp.
In search of the next great programming language: “reading code today is like reading baking recipes that includes details like exactly where in the kitchen the different ingredients are stored, but excludes the name and picture of the meal you're trying to prepare. The point I'm trying to make is that we should be communicating more with names and pictures, rather than a list of instructions in excruciating detail.” I’m not going to spell it out for fear of being accused of falling prey to the hype and so on, but: guess who’d also have better code understanding “with names and pictures”?
