491–500 of 511 posts
Earlier quoted context omitted.
My computer has man pages. They're usually pretty great! failing that, most of the APIs i use are open source, so i can read the code anyway.
you could also run a local LLM to browse your endless manpages efficiently ;)
Earlier quoted context omitted.
> If you can't understand why the code is done in a certain way from reading it then the code is missing comments or needs to be refactored. Code is never missing contexts. If what your code is doing is not obvious to the reader, it is bad code that needs to be fixed. Things like cryptic low-level expressions should be extracted to helper functions with descriptive names or even extracted into a class, and classes ne…
Ah the classic thinking that 'code documents itself'. It does not. Some devs are so full of themselves they think their code is so good that it is obvious what their intent was. It never is obvious, and just ends up as tech debt. Write comments.
This is demonstratably false. Case in point: all the code that does not require comments for developers to understand what it does.
> Some devs are so full of themselves they think their code is so good that it is obvious what their intent was. It never is obvious, and just ends up as tech debt.
That's why you need to address the problem in the PR stage and aggressively refactor code that fails to be clear.
This is not rocket science.
> Write comments.
No, that's just compounding the problem. Now you attached comment noise to cryptic code, which means not only do you still need to decipher the hot mess of a code you cannot parse on your own but you also have to parse the comment next to it to try to understand both.
And God forbid they get out of sync.
The solution is already known for over a decade: write clear and obvious code. Extract weird expressions into helper functions.
Earlier quoted context omitted.
> yeah that's how a simple algorithm that would fit on a napkin gets broken up into a soup of ravioli that I have no hope to understand. No, not really. You get spaghetti code by being unable to refactor your code to follow inconsistent level of detail across calls. That's the textbook definition. Once you start to follow basic code quality and software engineering principles, you'll notice right away that your code…
My code is fine, thanks. It's other people's code that I have a problem reading.
Earlier quoted context omitted.
> yeah that's how a simple algorithm that would fit on a napkin gets broken up into a soup of ravioli that I have no hope to understand. No, not really. You get spaghetti code by being unable to refactor your code to follow inconsistent level of detail across calls. That's the textbook definition. Once you start to follow basic code quality and software engineering principles, you'll notice right away that your code…
My code is fine, thanks. It's other people's code that I have a problem reading.
I find myself spending on average more time in LLM review/resolution loops than it would take for me to write the code by hand. Partially because once I'm in the flow I write very very quickly and the code pours out sometimes faster than I can write. But also because the LLM code on the first few tries is generally really really bad. What I find interesting though is that spending the time to personally review and di…
This feels like a comment from 2 years ago; by now the most modern models write much better code than humans can in much shorter time. But if you're not used to code reviewing, it can certainly help to still write yourself.
Earlier quoted context omitted.
> LLMs flip positions when users push back Same experience. Claude rarely pushes back once you give a plausible/logical reason for your initial decision, even if it flagged concerns at first.
I have noticed this as well, but I think it's somewhat a good thing. I know what I want for my application more than Claude does for example, especially when it comes to what's in production. An example from earlier, Claude strongly suggested a migration that would run a full vacuum on postgres. However, in production this would lock tables which would grind the application to a halt. After I informed Claude that the…
Contrast this with a human. We generally understand when the other person knows what they're doing and we should just listen, and when the other person is asking for an honest opinion and wants a push back if necessary.
Earlier quoted context omitted.
> LLMs flip positions when users push back Same experience. Claude rarely pushes back once you give a plausible/logical reason for your initial decision, even if it flagged concerns at first.
Skills help there. I have a linus-reviewer skill that focuses on architectural integrity, no bs, etc modeled on Torvald's code preferences. And I have an enrico-reviewer one (I'm Enrico), that focuses on correct design, strict typing, simplification. They have different prios, but they both push back on feedback, till you convince them.
I wouldn’t be praising an LLM for it’s voluminous output unless it is doing a much better job of finding actual bugs, and if the code really is that buggy then it might be worth asking why!
Earlier quoted context omitted.
I follow the same process. I have a design in mind for the problem at hand, but I don't reveal it to Codex. I go back and forth a bit to see if its proposals are better than mine. I go back and forth on tradeoffs of various approaches. And then I ask it to compare its proposals with mine. I "win" most of the time but there are many times where it shows a me a better, or simpler approach, or makes me rethink the solut…
I really like this pattern and use it often, this 'not showing my cards'. The second I hint towards the LLM what I prefer it will become sycophantic and invent nonsense why my preferred solution is better. I'm sure there's an interesting study on how users 'leak' their preference unintentionally to the LLM; perhaps when users list their options, they often put their prefered option first; but not showing the cards on…