On The Need For Understanding (blog.information-superhighway.net)

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.

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.

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.

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.

  #include 

  int main() {

    printf("Hello World");
    return 0;
  }