Last week, I offered my unused Linux laptop to my 7 year old. Let’s reinstall the operating system, I said, and then you can do whatever you want with the computer. I was hoping that an unexplored computer would fascinate her as much as it fascinated me when I was a kid.
For example, I told her, you can write letters to your friends and print them out. As imagination made her eyes go wide, I added that the printer is not a color printer. “It doesn’t matter!” That evening she printed her first letter.
Later, right before she was supposed to be sleeping, her voice came through the baby monitor that hasn't been a baby monitor for years but a slowly falling apart walkie-talkie: …ksshhh… pshht… the computer even has a calendar! a calendar!!…
Gina Trapani’s Life in Weeks — wonderful website. The Internet should be full of websites like this one. (Aside: through that site I learned that Postlight was sold in 2022, to “NTT DATA, the biggest IT services firm you've never heard of, the company that invented the emoji.”)
One million thousand times yes: “Every line of code you write is a potential bug. Do not write any line of code unless you absolutely need it right now and your program will suffer for the lack of it. Do not write routines speculatively. Do not write abstraction layers you don’t need right now.” It’s always surprising to me when I meet someone who’s programmed for a few years and hasn’t learned that lesson — where you have been? what have you not seen?
If you only read one thing from this list, let it be Harper Reed’s description of his “LLM codegen workflow atm”. The different tools, the different approaches, the different prompts, the meta-prompts to get other prompts, the combination of tools — this is it, this is it, this is what you have to do to break through “I’m not sure about AI and LLMs” wall: you have to bang your head against it until, suddenly, it breaks and you realise that, oh, if I do this, and then this, and if this gets better, then… okay, I see.
Came across this 2018 post by John Regehr, compiler man, about The Basic Toolbox. It’s aimed at new computer science students and reading through it gave me some funny feelings: yes, there was a time when I had none of these tools, wow.
"Perfect code doesn't guarantee success if you haven't solved a real problem for real people. Pursuing elegance in a vacuum leads to abandoned side projects or frameworks nobody uses." That’s from Armin Ronacher’s wonderful and wonderfully-titled post Ugly Code and Dumb Things. Thanks to that post I also learned that Sentry’s development philosophy includes “embrace the duct tape”, which I loved, and Armin adds: “Yet as Sentry matured, much of our duct tape didn't stand the test of time, and was re-applied at moments when the real solution would have been a solid foundation poured with concrete.”
These keep popping up and all of them seem to have a slightly different angle that makes them interesting: codename goose is an “on-machine AI agent, automating engineering tasks seamlessly”. But I’m not sure what “on-machine” means exactly, since it seems to talk to all the LLM providers we already know.
Another one: Claude Engineer v3.
What makes entrepreneurs entrepreneurial?, by Murat Demirbas, contains this golden nugget: “On his dream software team, he wants either Jeeps or Ferraris. Jeeps go anywhere. No roads, no directions—just point them at a problem, and they’ll tear through it. That’s effectual reasoning. Ferraris, on the other hand, need smooth roads and a clear destination. But once they have that, they move fast. He doesn’t want Toyota Corollas. Corollas are slow. Worse, they still need roads.”
Daniel Lemire said “programming should be taught like music with repeated practice” in response to Gordon Cassie wondering whether “programming should be taught more like an instrument where you have a private hour long lesson with the teacher and then go away for the week and work on what you learned by yourself.” I thought of that exchange yesterday when I dropped my daughter off for her piano lessons, saying to her: it’s not the lesson, it’s what you do in between lessons.
Another website lover’s website: everything you ever wanted to know about the XOR operator and then some.
Craig Mod shared this gist with an Alfred script that takes rich-text HTML in the clipboard and turns it into Markdown — neat. But through that I found another website: rich-text-to-markdown.com. Lovely! Not only because of how the Markdown is formatted (even though it’s strange?), but also: another single-use website! They’re amazing! everytimezone.com! bitwisecmd.com! If you have others, send them to me, please.
Analysis of the curl codebase: “It means that every line in the product source code tree have by now been edited on average 3.5 times.”
“N period on from now, software engineers who haven't adopted or started exploring software assistants, are frankly not gonna make it”, writes Geoff Huntley. He also describes “six stages of AI adoption” and the last stage is “Engaged, realization that LLMS can be programmed and doing it”. I’m not sure how I would order any stages, but I have to say that using LLMs programmatically was the most lightbulby moment I’ve had in the past year.
Once relatable: “Many of your friends and colleagues are excited, and you want to be excited, but you just can’t. The AI is simply not there yet.”
Good post on “a year of uv: pros, cons, and should you migrate”. I don’t particularly care about the challenges of the Python ecosystem, but I’ve found myself having to run Python code a lot in the past six months and uv always seemed like the solution to all my Pythonic problems, but I never really got the hang of it — until this post. It also taught me about uvx and how I can use
uv run.Here I wanted to link to this post that answers the question of why blog if nobody reads it? “You write because you think, because you observe, because you need to put it somewhere. If someone reads it? Bonus. If not? The work still got done.” Then I realised that the author moved the blog between the time I found it and the time I wanted to link it — another blogging lesson?
Not sure how I didn’t know about codecatalog.org but discovered it this week and spent quite a bit of time there. It’s a “collection of instructive code examples with annotations”, taken from open-source projects in different languages. That doesn’t say much, granted, but click through and look around. Each post is relatively short and mainly focused on the code — it’s nice.
Interesting post on scarcity mindset and why creative people are “so vulnerable to this kind of thinking”. I don’t think Steven Pressfield would agree with a lot here, but it’s interesting nonetheless.
Thought-sparking: Why Agent Experience Matters. The prediction is bold: “Generic SaaS tools will increasingly be replaced by custom developed internal applications. […] As the cost of building and deploying continues to go down, the number of web apps and sites will explode. For all software companies, this shift demands a fundamental change in mindset: start consciously designing the AX of their products, or risk being replaced by tools that empowers their customers to harness the exponential power of seamlessly collaborating with agents.” I’d love to see “the number of web apps and sites” explode, but I’m not sure if the cynical part in me can ignore the echos of “if every website would just have an API” from a decade ago.
Satya Nadella was on the Dwarkesh Podcast. Lots of big ideas and big thoughts and big questions, but my mind got stuck on what Nadella said about “what needs to happen with AI being introduced into knowledge work”: “Lean became a methodology of how one could take an end-to-end process in manufacturing and become more efficient. It's that continuous improvement, which is reduce waste and increase value. That's what's going to come to knowledge. This is like Lean for knowledge work, in particular. And that's going to be the hard work of management teams and individuals who are doing knowledge work, and that's going to take its time.”
Waiting for Benedict Evans to comment on this.
I was reminded of Joscha Bach’s first appearance on the Lex Fridman podcast. I remember exactly where I was when I first listened to it and how often I stopped walking to write something down. If you enjoy thinking, listen to this.
Apple released a new iPhone this week. It’s called the iPhone 16e and most accounts were pretty calm about it: just another iPhone, but this one’s cheap. Other accounts, though, such as this tweet by Mark Gurman, pointed out that this isn’t just another iPhone release, but that it has the C1, the first modem developed by Apple itself: “The C1 Apple modem is a monumental technical achievement. A several billion dollar effort that has been in the works for 7 years. In the end it gets two sentences in the press release and 15 seconds in the announcement video. Apple is clearly downplaying this intentionally.” Now, some of you know that I’m a big admirer of Apple’s M-class chips and that I still don’t know how they pulled them off. And when I now read Reddit comments like this one (“Many engineers have said that it might be near impossible to build this. I've been following the rumors for years and heard stories of how RF engineering is just impossible, with tons of weird edge cases, interference issues and unpredictable physics.”) or tweets like this (“you get to choose how you design the noise/attenuation environment inside a CPU, but a radio lives in the open world. So much institutional knowledge/magic in solving a zillion failure modes you can't just design/assume away.”) or HackerNews threads like this one about how hard it is to build a modem — I can’t help but wonder: are they pulling off another M1, except it’s now the C1?
