Kernighan on Programming

Kernighan's Lever - https://linusakesson.net/programming/kernighans-lever/index....

This article is perennially posted here and is probably the best breakdown of this quote.

So is reviewing and verifying code. Maybe not twice as "hard" if you're skilled in such things. But most programmers I've worked with can't be bothered to write tests let alone verify correctness by other means (good tests, property tests, types, model checking, etc).

It's one thing to point out small trivialities like initialization and life time issues in a small piece of code. But it's quite another to prove they don't exist in a large code base.

Kernigan is a good source of quotes and thinking on programming.

[dead]

In the age of LLMs, debugging is going to be the large part of time spent.

The real question is whether “debugging” the LLM is going to be as effective as debugging the code.

IME it pays dividends but it can be really painful. I’ve run into a situation multiple times where I’m using Claude Code to write something, then a week later while working it’ll come up with something like “Oh wait! Half the binaries are in .Net and not Delphi, I can just decompile them with ilspy”, effectively showing the way to a better rewrite that works better with fewer bugs that gets done in a few hours because I’ve got more experience from the v1. Either way it’s tens of thousands of lines of code that I could never have completed myself in that amount of time (which, given problems of motivation, means “at all”).

Reading this article seems outdated and therefore quaint in some areas now, the “we’ve all felt that moment of staring at a small bit of simple code that can’t possibly be failing and yet it does” - I so rarely experience this anymore as I’d have an LLM take a look and they tend to find these sort of “stupid” bugs very quickly. But my earlier days were full of these issues so it’s almost nostalgic for me now. Bugs nowadays are far more insidious when they crop up.

Is there any evidence for these assertions?

Wouldn't it make intuitive sense for "writing new code to do a task" and "tracking down a problem debugging code" to be multiple different skills and not the one same skill? Wouldn't it make sense for the one you do more of to be the one you are better at, and not directly 'smart' related? Wouldn't it make sense if tooling could affect the ease of debugging?

One of the few living oldschool UNIX legends still alive.

Here is when he was young:

https://www.youtube.com/watch?v=tc4ROCJYbm0

Kind of explains in an epic manner why pipes were useful back then.

They are still useful, but computers are so much more powerful that many techniques back then came primarily because their computers were not as powerful. I still, oddly enough, prefer the hardware of the 1970s, 1980s, almost early 1990s too. Today's hardware is much better, but I am nowhere as interested in it; it is now just like a common tool.

   foo | bar | baz

I consider a lot of my cleverness when writing code is aimed at achieving functionality, performance, conciseness, etc., while being easy to understand and self-debugged by design. The latter meaning:

• Types enforce safety

• Very tight dependencies

• A tight design (value, store, control flows) where most bugs are likely to be catastrophic, or at least highly visible, as apposed to silent. It works, or it doesn't.

• Use naming and code organization first, concise comments second, and a page or two of doc if all else fails, to make any non-intuitive optimization or operation intuitive again. (Clarify as needed: what it does, how it does it, and why that specific method was chosen.)

For me, a bug repellent design is more important than tests, during development. Except where there is truly messy functionality that no implementation can un-mess. Or results are not used in any way that creates implicit tests them. I.e. they are an intermediate solution to a downstream problem that is not part of the development context.

That seems so basic to writing the "most cleverest" code, that the quote makes little sense to me.

I spend a very small percentage of my time debugging, outside of the real-time development-time write, run, correct loop. If debugging ever took a significant fraction of time, it would give me some serious anxiety.

But as the article states, that may be the result of learning from my less manageable cleverness on ambitious personal projects, over and over, early on. Endless personal projects, in which any success immediately brings into view "the next exciting level" they could become, often requiring a redesign, are great for forcing growth.

A good QA team will just run the main tests for you and break your soul while doing it. But the end result is a system that has been broken by humans and not theories on how you can break business logic.

Isn't it so interesting that AI will completely destroy the motivation to be more clever?