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?”
Jons Mostovojs@inthehands any HR worth their salt will tell you that you use the word "programmer" to address multiple professions and even roles.
That said, I'm happy when software engineers are asking themselves the latter two questions you've listed. But they don't have to, in principle.
If your coop or a company doesn't have processess that concern discoverability and understandability, then it's not software engineers' responsibility to eyeball those, nor will it end well for anyone, because they're not professional technical writers / technical HR.