As shared by on Simon Willison’s blog, Zig has an interesting anti-LLM policy for contributions in their code of conduct.

Zig values contributors over their contributions. Each contributor represents an investment by the Zig core team - the primary goal of reviewing and accepting PRs isn’t to land new code, it’s to help grow new contributors who can become trusted and prolific over time.

I don’t think an anti-LLM policy makes sense for most projects. But a programming language requires considerate intent and deep knowledge for changes. It’s an interesting fit there.

In addition:

If a PR was mostly written by an LLM, why should a project maintainer spend time reviewing and discussing that PR as opposed to firing up their own LLM to solve the same problem?

We’ve historically preferred PR contributions over issues, because it puts the contributor in the position to do most of the work. But if a PR is just a contributor prompting an LLM, is a well-written issue preferable? When writing code becomes cheaper, might as well let the maintainer get it done using their taste.

Making Go’s generic context deadline exceeded errors traceable with small helpers that attribute the operation that timed out and indicate how long the timeout was.

I’ve always been intrigued by Go. It’s powerful, fast (I really like fast), and simple. The tradeoff? It’s simple. Coming from higher level languages like PHP & JavaScript, Go can feel crude.

As I’ve recently written, this blog went back to Hugo. Hugo is also fast and crude. But with LLMs, the crudeness of things doesn’t hurt as much as before. I don’t need to deal with writing it anymore, and crude is still readable.

From Just Fucking Use Go:

The boring choice is the right choice. It always was.

I agree. More than ever, I have an urge to dabble into lower level languages. AI is a huge layer of complexity we’re adding to our tooling. Let’s use it to trim the fat from our outputs.

Highlights

• I’ve completed all 22 chapters of my book.
• I thought AI made prototyping faster, but now I’m not so sure.

Goal grades

At the start of each month, I declare what I’d like to accomplish. Here’s how I did against those goals:

This is an older post from Jim Nielsen on building user interfaces I came back to last week.

With software, the fact is that sometimes there are just too many variables to know and test and smooth out. So I click around, using the UI over and over, until I finally cannot give myself any more splinters.

I feel this. I’m better at my job when I’m actually using something. Even better when I’m using something because I want to use it.

I’ve been building a side project on and off for a few months now. Having it my phone’s homescreen and actually using it every day gives me a different perspective on it than just building it and shipping it to others, like is often the case for client work.

Sand it, feel the grain, get a splinter, sand again, and repeat until smooth.