Live data from Hacker News

Learning Programming in an Age of LLMs

blog.ploeh.dk

151–160 of 190 posts

Re: Learning Programming in an Age of LLMs

#151

Earlier quoted context omitted.

It's not about what the customer complains or notices at short term, is about having a quality system that can be augmented without accumulating same kind of debt. I can give a simple example. I have a coder here that filled the crontab of a server with periodic tasks. One of them was doing +200 failed requests per second and shutdown one of our routers. The router wrote so much logs that it changed the health of its…

> It's not about what the customer complains or notices at short term, is about having a quality system that can be augmented without accumulating same kind of debt. I agree with this wholeheartedly, but convincing nontechnical management of this fact has been extremely difficult. It was hard in the days of the stackoverflow copy-paste monkeys, and it's even harder in the age of LLMs.

You have to pick metrics to show management that they understand the importance of, and then be able to demonstrate degradation in those metrics when you don't do what you propose, and improvements when you do. Accomplish this and you'll build trust.

Too often, what happens is that the proposed benefit is vague and not empirical, and then the benefit is not actually realized by a large investment into it, destroying trust.

Re: Learning Programming in an Age of LLMs

#152
post #118

Earlier quoted context omitted.

> It's not about what the customer complains or notices at short term, is about having a quality system that can be augmented without accumulating same kind of debt. I agree with this wholeheartedly, but convincing nontechnical management of this fact has been extremely difficult. It was hard in the days of the stackoverflow copy-paste monkeys, and it's even harder in the age of LLMs.

Some people cannot be convinced of this, but some can, as long as you don't use technical language to describe the issue. Essentially, instead of saying "we need to prevent technical debt and have a maintainable software architecture" one needs to say stuff like "software quality enables a faster time-to-market for new features and less customer churn". i.e. put it in business-y terms.

Yes, but then it's really important to demonstrate that this is true. If they invest in what you propose, time to market for new features needs to actually become faster, or customer churn needs to actually decrease. It's not enough to put the proposal in business-y terms, it has to actually effect the claimed improvements to the business.

Re: Learning Programming in an Age of LLMs

#153
post #149

> After months of refactoring I had an uncomfortable realization: I may have built a system that is above my own level of understanding. When everything works, that gap is almost invisible. When it doesn't, it becomes very real. > "Sometimes I genuinely don't know what to do next without asking another model. That made me wonder whether I spent a year building a product, or partly building the appearance of one: some…

Accurate.

I've wrote a rather large system that runs a medium business, solo. When a bug pops up, I feel unfamiliar with the code. It was all written by hand with 0 LLM usage.

It is normal to feel this way. However, I am still very capable of resolving the issues in a timely manner. Adding any new big features is a big undertaking and usually involves a lot of refactoring to fix the dumb decisions I've made.

Re: Learning Programming in an Age of LLMs

#154
To me software engineering was often about: how do we structure the project so that the crappy code the other students/co-workers write don't break everything?

Not because everyone writes bad code. They do, at-least the do first time you read their code. You only think someones code is decent when you spent 3 hours trying to refactor their PR, and realized that the compromises they made were perhaps reasonable. (This is an important lesson to learn)

Whether code written by others is poor or not is also besides the point. You cannot keep everything in a large project in context (biological or not).

Software engineering (not computer science) is about: managing complexity. Structure your project in layers or abstractions or packages or silos or verticals or objects or whatever.

But break complexity into bits, so that everything isn't in mind all the time.

Nothing new about that. And poor engineering can be papered over with hard work. It's just easier to reach the point where poor engineering really bites ;)

Re: Learning Programming in an Age of LLMs

#155

Earlier quoted context omitted.

That’s the power of abstraction when there’s a good API around something to hide the internal that doesn’t matter much at an higher level. You only need ‘open’ and ‘read’ instead of dealing with disk access and file system trasversal. But those abstraction are deterministic in nature, so there’s a very good guarantee of their behavior. Someone using LLM and not caring about the generated code is just asking for troub…

> The code may work, but there’s no guarantee about its behavior (including error handling and edge cases). But the painful reality is that we never had any such guarantees in industry code to begin with; despite decades of writing on software engineering best practices, software from the biggest companies is often bug ridden. My experience might not be representative, but when I do my "old man yells at clouds" routi…

> it's a lot more often targeted at Microsoft and Google software than at "vibe coded slop".

What makes you confident the Microsoft and Google software isn't vibecoded slop?

Certainly Microsoft has made a lot of noise about all their software being LLMgen these years, and also gotten into hot water with their users for Windows 11's crappiness.

Re: Learning Programming in an Age of LLMs

#156
post #58

I answered this to myself - stop worrying about LLMs. It's pretty simple: due to Curry-Howard isomorphism, programming languages are just notations for some type of formal logic. Now ask yourself a question, what language do you want to maintain the programs in? Do you think natural language is going to be easier and more maintainable than formal logic? The answer is no. So you need programmers, people who can read t…

I totally agree with the skepticism that we'll ever get to a point where natural language becomes the "formalism" and stop needing people who understand the actual formalism underneath. And I agree that you don't need LLM based tools. But things that you don't need can still be (and often are) incredibly useful . Nobody needs an IDE, nobody needs vim or emacs or bash or even compilers or assemblers. But we have all t…

Also not everything needs to be formal.

I might want the REST API for a webshop to be solid, payment and checkout process, sure.

But the UI. So long as the LLM doesn't falsify product information, why customize the layout, theme, look and feel for each and every single customer.

Okay, maybe don't, but point is: you could take bigger risks, you maybe don't need to review UI changes as much.

Re: Learning Programming in an Age of LLMs

#157
post #146

Earlier quoted context omitted.

> Some things you need to understand-others, not so much. This is the core of the matter though, knowing what you need to understand and what you can ignore is the actual programmer's skill. It requires you to have a clear mental picture of both what you are trying to build and what the underlying machine will do when you are finished. You need to understand the abstractions, but also where they leak, when they won't…

That's just it. you didn't "build so much", you didn't build anything. You asked someone (or something) to build it for you. How can people look at LLM-generated code and think "this is mine, I made this" is beyond me.

I’m in two minds about this, in some sense they did and it’s the same way in which the C code I write is mine, but the assembly underneath is an artifact of my intent, but I owe the compiler authors for it. On the other hand the cognitive distance between my C and the assembly is likely lower, but that’s because I’ve spent time staring at what was generated in order to figure out why my code was misbehaving. Which is itself not that dissimilar to figuring out how to get better at writing code with llms.

Re: Learning Programming in an Age of LLMs

#158
post #5

I'm the author of Python Crash Course, and I got this exact same email this week. I was thinking of writing a public response as well, because any attempt to sincerely answer these questions takes something along the lines of a full post. It's also worth a public response because many people who are getting into programming for the first time right now are asking variations of these same questions. > Do I think that…

I think there might be a take on learning with AI vs the pressure to develop fast. AI could be an amazing tool to learn. But who wants to learn when you had to deliver 3 days ago? The corp culture is kind of what is killing it. Not sure how things are going in universities tho. If you stop and use it to learn, take time, ask questions. I am sure you can learn a shit ton out of it, most people were learning in the beginning when you had to copy/paste/debug in chatgpt. If I had to answer to this, I'd say that learning has become optional, helpful, but optional. Not in the sense that it is not good to learn it (or anything), but in the sense that you need to opt to learn it, and to do so you will have to sacrifice speed. Do what I say makes sense?

Re: Learning Programming in an Age of LLMs

#159
post #65

Earlier quoted context omitted.

Extraneous and ambiguous is superior? Or are you talking about hypothetical new spoken languages?

Yes. Ambiguity is a feature, not a bug.

Yes all of my the customers of my accounting software love the ambiguity of how it will react to them processing entries.

You’re not saying anything with substance, but I guess that’s not surprising given your stance on LLMs.

Re: Learning Programming in an Age of LLMs

#160
post #5

I'm the author of Python Crash Course, and I got this exact same email this week. I was thinking of writing a public response as well, because any attempt to sincerely answer these questions takes something along the lines of a full post. It's also worth a public response because many people who are getting into programming for the first time right now are asking variations of these same questions. > Do I think that…

I think there might be a take on learning with AI vs the pressure to develop fast. AI could be an amazing tool to learn. But who wants to learn when you had to deliver 3 days ago? The corp culture is kind of what is killing it. Not sure how things are going in universities tho. If you stop and use it to learn, take time, ask questions. I am sure you can learn a shit ton out of it, most people were learning in the beg…

I'd quip this summary, only half tongue-in-cheek: "the goal was never to learn things".
Post reply on HN