This article articulates a lot of how I feel about using AI today. I can see that I will use it more, but I don’t know yet how to use it more while maintaining the level of understanding of the code I want to retain.
I attempt to set a high bar for what I want code to look like, and I want to understand the code I ship. Under pressure, or in a discussion with another human, I want to be able to explain what the system does without first having to ask [an ai model] to explain it to me. Now there is obviously a question if this desire to understand the code is one that I will still have a few years from now. For now I have not moved past the point of comprehension being important to me.
Given this desire, there is something I lack with my experience of code written without me paying attention, particularly from loops. Present-day models tend to produce code that is too defensive, too complex, too local in its reasoning. […] At least for my taste, present-day hands-off harnesses like Claude Code with ultracode produce worse code than what we were producing last autumn. That’s because Claude Code, with Fable for instance will be working uninterrupted on a problem for thirty minutes or more, when previously the process would have been much more human in the loop.
In a recent conversation, I realised I knew consistent hashing existed, and what you could use it for. However, I couldn’t immediately bring to mind how it actually worked. Not awful — I knew I could easily find out — but I also felt I should have known it.
I’ve found that a good way to get an algorithm to stick in my head is to implement it. Even better to then write about it. I remember the parts of toykv that I wrote about more clearly than those I only coded.
There are a few other algorithms that I like but I can’t quite remember. Rendezvous hashing and reservoir sampling come to mind as ones where embedding the idea solidly would be valuable. I’d also like a deeper understanding of bloom filters. I like data sketches, so perhaps I’ll be brave enough to look harder at hyperloglog and count-min. We’ll see how it goes.
So let’s start a small series here to get some more depth and memories of these useful algorithms. And where better to start than getting consistent hashing fixed securely into my brain.
Today I learned that you can make strongly typed CLI flags using Go’s standard
flag package. flag is a package I’m fond of and I’ve written about it
before. I think the package is
underappreciated and harbours hidden depths.
You make strongly typed flags in Go by implementing the flag.Value interface.
One thing I really liked about this approach is that it gives you a contained
place to validate flag values without polluting main!
Let’s explore the idea by creating a strongly typed flag that selects between pretty logs (for when you are developing) and JSON logs (for production).
I’ve been reading Rust Atomics and Locks by Mara Bos. If you’re into low-level concurrency primitives, it’s a great book. The rest of you can leave now 🙃
Memory ordering is a place where Rust and Go diverge, and I think it’s illustrative of the difference in language philosophy. Rust provides a selection of memory orderings per atomic variable operation, whereas Go provides just one. Rust chooses raw performance whereas Go selects ease-of-use.
Let’s dig in.
I finally got to reading Paul Ford’s opinion piece in the New York Times, The A.I. Disruption Has Arrived, and It Sure Is Fun. I’ve long nodded my head to Paul’s essays, and this wasn’t an exception.
Especially this part near the end, which gels with my (naive?) hopes about AI reducing the amount of software suckiness in people’s lives:
I collect stories of software woe. I think of the friend at an immigration nonprofit who needs to click countless times, in mounting frustration, to generate critical reports. Or the small-business owners trying to operate everything with email and losing orders as a result. Or my doctor, whose time with patients is eaten up by having to tap furiously into the hospital’s electronic health record system.
After decades of stories like those, I believe there are millions, maybe billions, of software products that don’t exist but should: dashboards, reports, apps, project trackers and countless others. People want these things to do their jobs, or to help others, but they can’t find the budget. They make do with spreadsheets and to-do lists.
My industry is famous for saying no, or selling you something you don’t need. We have an earned reputation as a lot of really tiresome dudes. But I think if vibe coding gets a little bit better, a little more accessible and a little more reliable, people won’t have to wait on us. They can just watch some how-to videos and learn, and then they can have the power of these tools for themselves.
I hope we can, though what that means for the professional programmer, I don’t know. Clearly there’s a lot of software where “probably right” isn’t good enough, perhaps that is where we will re-find our niche.