Hacker News Reader

> The real work is of course to understand what it is that you are really trying to solve with applying assumptions about correctness.

In how far do you think LLMs stand in the way of that?

My experience has been very much the opposite: Instead of holding the hard part of the process up by digging through messy apis or libraries, LLMs (at least, in their current form but I suspect that this will theoretically simply remain true) make it painfully obvious when my thinking about a task of any significance is not sound.

To get anywhere with a LLM, you need to write. To write, you have to think.

Very often I find the most beneficial part of the LLM-coding-process is a blended chat backlog that I can refer back to, consisting of me carefully phrasing what it is that I want to do, being poked by a LLM, and me through this process finding gaps and clarifying my thoughts at the same time.

I find this tremendously useful, specially when shaping the app early, to keep track of what I thought needed to be done and then later being able to reconsider if that is actually still the case.

This aligns with my thinking about the utility of LLMs: they're rubber duck programming as a service

I don't get so much from going over previous conversations, but needing to articulate a problem well enough to ask chatgpt a question is extremely useful. Far moreso than coming up with search phrases, I find.

This is how I’ve been most successful so far at using LLMs. They help me poke as you say at the problem until a satisfying solution appears or until I have enough info to know what to look for.

But that is a terrible way of dealing with hard problems.

I recommend Rich Hickey's "Hammock Driven Development" talk. You don't solve hard problems by poking at it repeatedly until something works, that is the recipe for terrible code and abstractions. You instead take a step back from your computer and digest it until you come with a well-understood solution.

This approach is what separates the experienced engineer from the junior. Code is the least of your problems.

I don't know what experience you draw from, and what is lost in assumption here (on both sides, "hard problems" is open to a lot of interpretation), but the entire premise behind agile is, that thinking a solution up is not how software development works. You chunk things up, you iterate, you stay flexible, precisely because sitting down and thinking hard is not realistically working for a sizeable, messy, real world business solution.

I draw from my 17 years of experience in the field, but I am well aware that people work differently.

There are the John Carmack types, whose output depends on how much time on they spend at keyboard, and the Rich Hickey types, whose output depend on how much time they spend on a hammock with their eyes closed (or under the shower in my case). I am afraid I am of the latter type. My best solutions are found away from the keyboard, as I have learned to simply depend on my subconscious to process and digest them while I'm doing other things.

Check out that talk still, it has deep insight on how the human brain operates.

Poke around as in, at least in my case, discussing and throwing ideas back and forth. this is not incompatible with hammock-driven development (big fan here). It's however a good way of "discussing" ideas and solutions, and has been working well for me as part of an overall strategy to solve my problems. (30 years of experience in the industry if we're counting)

There is an interview with the great jazz pianist Bill Evans (conducted by his brother) in which he muses that most amateur musicians make the mistake of overplaying. They go out to the club and hear a professional and they come home and try to approximate what the professional does. What they end up with is a confused mess with no foundation. He insists that you have to learn to be satisfied with doing the simple things and gradually building up a stronger foundation.

I think his insight applies nearly as well to using code generated by an ai.

When I look into the future, and I know that I really can't, one thing I really believe in is that there will be a shift in how quality will be perceived.

IKEA furniture is a great example of this. I build my own furniture and being around it is a much much nicer thing than some piece of cardboard from IKEA.but it seems like cost, soeed an convenience are the most important thing in peoples minds.

But the tradeoff of cost and convenience vs quality is everywhere in life. Most people (including me) do not have the time, money, nor (in my case most importantly) workspace to build their own furniture. IKEA and other budget furnishing companies are a perfect solution for people in this situation and I can buy a handmade piece of furniture if I ever feel that something is not up to quality.

Very well put, like what's the point of doing work of the art if the art don't accompany artist story of struggle, mental experience and creative expression while reaching to end form of his art. What ai model does is rob us all inate experience and give us only cream of end result, it's is like watching porn instead of forming real relationship with person to win the sex.

> LLMs is a disaster to our field because it caters to the average human fallacy of wanting to reach a goal but without putting in the real work to do so.

It's a tool. It doesn't make sense to blame the tool. Is it the screwdriver's fault it gets used as a hammer? Or a murder weapon?

Used intelligently Copilot & Co can help. It can handle the boilerplate, the mundane and free up the human element to focus on the heavy lifting.

All that aside, it's early days. It's too early to pass judgement. And it seems unlikely it's going to go away.