▲ | whynotminot 6 days ago | |||||||||||||||||||||||||
A good part of my career has been spent pair programming in XP-style systems, so chatting away with someone about constraints, what we're trying to do, what we need to implement, etc, might come a bit more naturally to me. I understand your perspective though. | ||||||||||||||||||||||||||
▲ | skydhash 6 days ago | parent [-] | |||||||||||||||||||||||||
That may be one of the reason for the conflict of opinions. I usually build the thing mentally first, then code it, and then verify it. With tools like linters and tests, the shorter feedback make the process faster And editor fluency is a good boost. By the time, I'm about to prompt, I usually have enough information to just code it away. Coding is like riding a bicycle downhill. You just pay enough focus to ride it. It's like how you don't think about the characters and the words when you're typing. You're mostly thinking about what you want to say. When there's an issue, I switch from coding to reading and thinking. And while the latter is mentally taxing, it is fast as I don't have to spell it out. And a good helper to that is a repository of information. Bookmarks to docs, documentation browser, code samples,.. By the times the LLM replies with a good enough paragraph, I'm already at the Array page on MDN. | ||||||||||||||||||||||||||
|