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?”
DesignDamon@inthehands So true, and there's a direct parallel with design here - It's not all about the execution and how good you are at making things look good in Figma. Do I have the insight/research I need to design the Right Thing? How will people use this? How well will it translate to build? Am I serving the user needs, and not my own ego? Are business needs pushing me to do something shady? Are the aesthetics appropriate, or just what *I* like? It goes on.
@inthehands AI/LLM "Design" approaches to to be focussed on *describing how it looks*, and not understanding the job it needs to do.
@damon
This is all very well said, and everything you said applies when writing the code as well. Developers and designers alike are too much in denial about how many design decisions are actually made by the implementers. That’s why communication and shared understanding, and iterative process, are so essential.
This is all very well said, and everything you said applies when writing the code as well. Developers and designers alike are too much in denial about how many design decisions are actually made by the implementers. That’s why communication and shared understanding, and iterative process, are so essential.