Joy & Curiosity #40
Interesting & joyful things from the previous week
This week a very experienced engineer reached out and asked me: “What’s the play? You seem to have it figured out. There’s so much going on. What do I do? What do you do? Aren’t you scared?”
These are wild times. “Software and tech,” I wrote to a friend in the week before, “as it was, say, from 2008 to 2022 — that’s over.”
But, somehow, even though the pace is unlike anything I’ve experienced before, it doesn’t feel that different to me.
My friend wondered whether “there’s a correlation here: self-taught engineers like us have it much much easier adapting to this wave. I think because we… never really rested easy.”
It made me realize that, yes, ever since I decided — back in 2011, after dropping out of college — to become a professional software developer, I have not once felt that I could pause, that I had learned enough, that I could ignore this new thing and be fine — there was always something else to learn, something I had to know just to catch up with everyone else.
So, no, I don’t have it figured out, just like I never have. But trying to learn, to understand, to improve — that hasn’t failed me yet.
Last week we made Amp available to everyone and, as a more practical companion to our lovely owner’s manual, I wrote about how I use Amp. If you ever wondered how I use agents when programming: a lot of it is in this post.
Ian Lance Taylor, one of the co-creators of Go, left Google. “But Google has changed, and Go has changed, and the overall computer programming environment has changed. It’s become clear over the last year or so that I am no longer a good fit for the Go project at Google. I have to move on.” I’m not sure if the data will back me up on this, but it seems as if a lot of great engineers are leaving Google lately — wild times, indeed.
This Andrej Karpathy tweet about prompts has been stuck in my mind for two weeks now: “a lot of human learning feels more like a change in system prompt. You encounter a problem, figure something out, then ‘remember’ something in fairly explicit terms for the next time. E.g. ‘It seems when I encounter this and that kind of a problem, I should try this and that kind of an approach/solution’. It feels more like taking notes for yourself, i.e. something like the ‘Memory’ feature but not to store per-user random facts, but general/global problem solving knowledge and strategies. LLMs are quite literally like the guy in Memento, except we haven't given them their scratchpad yet.”
Two more thoughts on prompting that I’ve shared multiple times now. Ethan Mollick: “Many of the most important ‘prompt engineering’ skills are just management skills: clearly understanding the task to be done and what information is needed to do it; explaining the task to the AI; giving useful feedback to improve outputs; & generalizing lessons learned into a process.” And Maria Antoniak adding: “My most common prompt critique is ‘this doesn’t make sense.’ Sometimes people write instructions that are impossible to follow and then report that the model can’t do a task. Not really news to anyone, but liberal arts (writing, philosophy, logic, critique) training is good for this kind of thing.” Prompting is hard because communication is hard and I think that’s why a lot of engineers struggle with it: it’s very hard to put into words what you want.
Okay, one more thought on prompting: “You can’t expect a human to figure out what you want if it has complete amnesia every time it does a single action”
Someone in the comments to Karpathy’s tweet linked to this paper on “Promptbreeder”, a system that enables “self-referential self-improvement via prompt evolution”. Wild stuff: “Driven by an LLM, Promptbreeder mutates a population of task-prompts, evaluates them for fitness on a training set, and repeats this process over multiple generations to evolve task-prompts”
Max Bernstein, whose blog has a lot of gems, wrote another two great posts. This one contains links to pieces of writing — blog posts, comments, code — that changed how Max thinks about PL and is a treasure. And then this one here, about building a search engine from scratch using word2vec, made me want to — you guessed it — build a search engine from scratch.
Would you look at that: another great Max Bernstein blog post. This one is about ZJIT, “a new just-in-time (JIT) Ruby compiler built into the reference Ruby implementation, YARV, by the same compiler group that brought you YJIT”. I really, really appreciate the clear explanation of the different IRs in play here.
I’ve been vaguely aware of the Odin programming language for at least a year but haven’t taken a closer look. Then along comes this blog post, saying it’s a “programming language made for me”, and now I’m very interested — the soa keyword in particular seems very, very interesting.
Michael Stapelberg wrote about his “2025 high-end Linux PC” — man, do I love reading posts like this. I’m not even into hardware or custom computer builds, but it reminds me of putting together computers when I was a teenager and knowing that out there in the world there’s a dude spending that much time setting up his computer, putting so much care and effort into it, and then writing about it like this — that makes my day.
Talking about dudes out there in the world doing stuff I’d never do: “with the following code, we can check whether a year 0 ≤ y ≤ 102499 is a leap year with only about 3 CPU instructions”. Now that’s some programming.
Justin Jackson is asking whether YouTube will kill the podcasting industry and while I agree with a lot of sentiments in that post, I was also surprised by how different my experience with podcasts is, or how different of a listener of podcasts I am. For example: I often "listen" to podcasts on YouTube, because I have YouTube Premium (which allows me to listen to a video on my phone, without having the app open) and it's very easy for me to click on a link while at my computer, watch a bit of the video, then go for a walk, open the YouTube app, and, there it is — my last watched video. Play, listen, don't finish, get back to computer and finish there. It’s so convenient that I haven’t even thought about it until I came across this post. Certainly a lot more convenient than anything in the Spotify UI. Or keeping track of RSS feeds.
This discussion was wild and certainly in the Curiosity and not the Joy column. But it did lead me to aider’s release history which starts by saying “Aider writes most of its own code, usually about 70-80% of the new code in each release” and then shows “percent of new code written by aider, by release”.
Lovely: “In 1986, Sony dropped the SMC-210, their first portable PC in the US”
For many years now I’ve wondered: how do people with long nails type on their laptops? Admittedly, it wasn’t a question that burned so strong in my mind as to make me go and find its answer, but still, it was a very sweet “huh, now I know” that washed over me when a colleague shared on our work Slack a link to tippytype.
John Siracusa wrote two posts on Apple. The first one is called Apple Turnover and ends with this: “It’s time for new leadership at Apple. The road we’re on now does not lead anywhere good for Apple or its customers. It’s springtime, and I’m choosing to believe in new life. I swear it’s not too late.” The second post, Apple Turnaround, then describes “the things I think Apple should do, but that its current leadership seems unwilling to budge on”. That’s John Siracusa writing this. John Siracusa!
Sean Goedecke with some very “practical AI techniques for daily engineering work”. I love the “Throwaway debugging scripts” technique. Using LLMs to generate scripts that I would’ve never written myself led me to wonder: how much of programming is about reducing the need to write more code in the future and how much of that is no longer necessary when you can now generate code a lot faster?
More practical advice from Sean Goedecke, but this one is… different: “The good times in tech are over, at least for now. It’s not just a tough job market, but a tough environment for already-employed software engineers.”
If you read my post on how to build an agent in around 300 lines of Go and thought “that’s around 291 lines too much”, I have some good news: this post by Philip Zeyliger shows what an agent is in 9 lines of pseudo code.
Don’t ask me why because I don’t know, but I ended up reading a lot about Navy SEAL Team Six in the past two weeks and if the two of us should ever meet and go out for a drink I will talk your ears off with my very superficial knowledge of Navy SEAL Team Six, but here I want to share just one very interesting bit from that Wikipedia article: “According to Marcinko's book Rogue Warrior, SEAL Team Six members were chosen if they had initial struggles qualifying in aspects of training, but subsequently qualified, as the determination of these candidates was seen as more valuable than a candidate that breezed through his training.”
