On The Need For Understanding

I think as an industry LLM assisted programming is largely amplifying an existing gap: commercial software is often under much higher speed constraints and much lower correctness constraints than the sorts of software that can be created by deeply understanding a software system.

Obviously this depends on the industry; aviation software that runs in regulated environments is probably under even higher correctness constraints than that which Sussman discusses. Accounting software too needs to balance books correctly or risk fines. But most software needs to be mostly correct. New features and better UX is more useful for the users of many systems than fixing tail frequency bugs.

Personally I do hobby code on systems I understand from scratch. Writing for older, well documented retro hardware for example is very fun. Writing things from simple abstractions is also fun. But my speed in doing this is something I know is not commercially viable and that's fine by me.

Many fields have a commercial aspect of them that has a much lower quality bar and a much higher output speed bar than their hobby equivalents. Wedding photography, voice acting, the quotidian demand for these things is far lower than appreciating an Ansel Adams piece in a museum.

It's pleasant to read an article that genuinely seems written by a person; warts and all. It doesn't matter that it repeats some of its points. Actually maybe that's the point. I hope more people try this.

This article helped me understand something I've been grappling with for a while.

I've been looking for the optimal game development environment for a while.

That basically boils down to having batteries included. (I have the opposite of Jonathan Blow's situation, I need to be able to get up and running in a few hours for game jams.)

But there seems to be this tension between convenience and control. Either APIs are low level or they are high level.

(A notable exception is the canvas API, which leaves both groups dissatisfied :)

The article basically made me realize, those are basically two separate groups of people. There's people who want total understanding and total control. And there's people who want to Do Thing With Computer.

I am not sure if it's possible to design one system they would both be happy with.

But that made me realize, I had the same idea about GUIs 20 years ago.

On Mac you usually don't get many options. On Windows you usually get too many options.

A rare few applications let you switch between two modes. "Just Do Thing" and "airplane cockpit". There's usually a gear icon or something like that which shows you all the extra options.

I wonder what that might look like for an API.

There are a few emotional trigger points that LLMs seem to cause in programmers and this is a common one -- the need for deep, first-principles understanding that LLMs make obsolete.

One thing that gets me in a lot of pieces like this is they kind of assume people have no agency, that now that these tools exist we won't be able to help ourselves but use them despite our better judgement.

The broader topic which I don't see discussed so much are values. If you value deep understanding, well you should continue programming and learning in such a way. In some cases you may just want to use a language model to spin up a quick tool or PoC. And there is an entire grey area in between. It's a value judgement to decide what you use LLMs for, as much as what you don't.

My degree is in math, I love Dijkstra, and I think a lot of my colleagues have often created more work than necessary for themselves by treating pieces of code empirically when they could have got a more precise understanding by spending an hour reading it carefully.

However, I think the most fascinating thing about Dijkstra is how wrong he turned out to be in his prediction that an empirical approach would not scale.

I suspect that approaching programming like Dijkstra might have paid off long-term, but it was rarely a good deal in the short term, both for bad reasons (the empirical approach is a quicker and cheaper way to create buggy software that we can sell and claim as achievements on our performance reviews) and valid reasons (the unreliability of humans and hardware ultimately forces us to approach real computer systems, which are always a composite of hardware, software, and humans, empirically anyway.)

I have experienced that people who understand the problem and simply solve it do not pass interviews. I've experienced this from both sides of the interview and I was just as confused by my fellow interviewers as I was by the companies I interviewed at. It seems like companies would prefer you to wrap everything in classes, spread the code across several files, and make N+1 copies of data, instead of writing 50-100 lines to actually solve the task.

When documentation is lacking, if the 3rd party library is source-available then reading the source code is my next step. This almost never fails me. Source code is usually understandable, generally speaking many brilliant people have put in decades of effort to make source code and the tools we use that way. I've long considered that the ability to understand source code by sitting down and reading as the most important asset a developer could have. Given that, I wonder how the latest trend seemingly against understanding source code will turn out. Maybe it will turn out to be less important, who knows. But it is really weird to live through.

The Android example is a bummer. After this many years and generations of GUI frameworks, you should not have to experiment nor dig into source code to learn how to do something as simple as laying out your widgets.

The docs should have examples for that kind of thing.

This excellent article reminded me a lot of something I tried to get at a while back:

https://journal.stuffwithstuff.com/2010/11/26/the-biology-of...

When I wrote that article, it didn't seem to resonate with anyone at the time. I've been thinking about it more lately in the era of LLMs.

Access to source code is enormously useful for understanding the behavior of any API you have to call.

I feel weirdly fortunate I came up working on open source CMSes in the late 00's --- the docs were typically woefully inadequate, but it taught me to read source and then drop debuggers and trace to confirm my theories about how the source behaved. Often when I see programmers hit a wall, they are for some reason stuck on poking at the underlying code like a black box instead of just trying to understand it. And understanding complex code is hard intellectual work, but to me it's always been more fun than the guess and test of pretending the source is closed.

Interesting piece - reading it I found myself skimming, the point being made was being made repeatedly, albeit showing that as the author grew as a developer so did the complexity of the software they were using.

There was one thing that screamed in my head, though, whilst reading it, was, yes we can have a look at the library being used, read the code, and understand what its actually doing (this is one of the reasons I like Go so much, no matter who the upstream author is it's generally clear what they're doing [caveat: there are always going to be authors that obfuscate the f*ck out of code, no matter the language], the one thing, though, is systems like Netflix, hundreds of microservices running together in ways that people have NFI what it's all doing.

It just doesn't fit into one person's head anymore.

So, a single head can manage the data pathways for some subset of the system overall, and they might even get right down to the metal, the sheer size of the system means they only have a partial view, and abstractions (in the form of C4 diagrams) only show how complex the beast has become.

i've been thinking about this a lot the past few days, particularly about how coding agents can _help_ with understanding

i've been using opencode/opus to help with debugging lately, and it (he?) will happily dive into the source code of a dependency, the dependency's dependencies, and the C code that its binding to, all the way down to reading the libusb driver code and explaining what is going on where

whether or not i could have figured that all out on my own is beside the point; i wouldn't have take the time on a tight deadline to dig in deep. i would have done some poking and experiments and shipped a hacky workaround

I was relieved to read (skim) through all of that without it reaching some LLM conclusion like, “of course we have a better vantage point to understand now than thirty years ago... the LLMs can understand for us”.

I can't imagine programming without understanding aka vibe coding. Hence I will never vibe code.

In the world that the AI bros want for us, understanding has become a hobby.