3 ms·
> 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
by jstummbillig 3y ago
> 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.
- peterashford 3y agoThis aligns with my thinking about the utility of LLMs: they're rubber duck programming as a service
- Yodel0914 3y agoI 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.
- weikju 3y agoThis 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.
- sph 3y agoBut 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.
- jstummbillig 3y agoI 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.
- sph 3y agoI 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.
- weikju 3y agoPoke 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)