Live data from Hacker News

On The Need For Understanding

blog.information-superhighway.net

31–40 of 49 posts

Re: On The Need For Understanding

#31

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…

> deep, first-principles understanding that LLMs make obsolete.

I don’t think that’s the case. I agree with the rest of what you wrote. But it’s not a value out of thin air. You need understanding, unless all you ever do is “spin up a quick tool or PoC”. And even then it depends on what you want to quickly use the tool for, or what concept you want to prove.

Re: On The Need For Understanding

#33
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.

Re: On The Need For Understanding

#34
post #12

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

What do you do to learn new programming construct? What did you do to learn programming - didn't you write #include int main() { printf("Hello World"); return 0; } while having no idea what 'stdio.h' is?

When you first learn anything you don't really understand it - that takes longer. When you learn woodworking you won't know why you have to hold the saw a certain way. When you learn chemistry you don't know how we know atoms exist. You start by doing the fun stuff and fill in the gaps later.

Re: On The Need For Understanding

#35
post #28

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…

As they say in a somewhat different context: worse is better

Re: On The Need For Understanding

#36
post #11

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 was the most delightful thing I've read in a long time.

Re: On The Need For Understanding

#37

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 con…

> New features and better UX is more useful for the users of many systems than fixing tail frequency bugs

If nobody notices a bug, does it matter?

There's whole classes of technically bugs that simply never happen under the real world operating constraints of a software system. The infamous example is that memory leak story from the Microsoft blog[1] – you don't need to fix memory leaks on a rocket that goes boom (or runs out of fuel) after 5 minutes of flight time. Just add the extra memory chip and move on.

Engineering is all about building to real world constraints. Don't build a suspension bridge where a sturdy plank will do.

[1] https://devblogs.microsoft.com/oldnewthing/20180228-00/?p=98...

Re: On The Need For Understanding

#38
post #37

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 con…

> New features and better UX is more useful for the users of many systems than fixing tail frequency bugs If nobody notices a bug, does it matter? There's whole classes of technically bugs that simply never happen under the real world operating constraints of a software system. The infamous example is that memory leak story from the Microsoft blog[1] – you don't need to fix memory leaks on a rocket that goes boom (or…

It's not a bug if someone designed it to work that way though - a no-op allocator is an allocator too, and can also be used on short-running processes (even outside of things that go boom).

Re: On The Need For Understanding

#39
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

Re: On The Need For Understanding

#40
post #8

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

The two don’t have to be mutually exclusive. You can let the agent code and you review it, or vice versa. No different from being a team lead where you don’t write all the code, or even review each and every line of code, but you have a very firm grasp of the code base.

In theory, vibe coding and understanding don't have to be mutually exclusive, but in practice, I think that the people who have the discipline to actually maintain their understanding of a codebase are few. I've code reviewed things from people who claim they are reviewing what comes out of the LLM carefully, and talked to them about the code, and while they think they understand the code, they simply don't, which becomes abundantly clear when I try to explain the problems I find in the code.
Post reply on HN