Paul CantrellThis is good (from @shriramk): https://mastodon.social/@shriramk/110040524796761802
The skill of recognizing and diagnosing broken code only becomes •more• important in the face of LLM code generators.
Any experienced programmer worth their salt will tell you that •producing• code — learning syntax, finding examples, combining them, adding behaviors, adding complexity — is the •easy• part of programming.
The hard part: “How can it break? How will it surprise us? How will it change? Does it •really• accomplish our goal? What •is• our goal? Are we all even imagining the same goal? Do we understand each other? Will the next person to work on this understand it? Should we even build this?”
Zorro Notorious MEB 😡@inthehands Where I come from, what you describe as "the hard part" is called "spending too much time in the huddle" and you can get fired for it. 😈
@AlgoCompSynth
If folks are only thinking about all those things while they’re in the huddle, you’ve got problems.
If folks are only thinking about all those things while they’re in the huddle, you’ve got problems.
@inthehands If the development staff has to think about those things you've got problems anyway. "Should we build this?" should have been decided long before making other decisions. But "should we stop building this?" has to be on the table.
Ralesk@AlgoCompSynth @inthehands If someone sells a feature that's infeasible it's much worse to later say no, than to not sell it at all - so dev layer input can be important