You're right, except you sell your own answer short when you say "curve". In practice, the set of trade-offs has a much higher dimensionality, and solutions are much less often strictly "wrong" as they are "less optimal" or "out of scope".

Now, you might be thinking "that's not true, if I implement a function to add two numbers, and it returns 1+1=3, that's wrong. So that's a clearly wrong solution." But I argue: is it wrong? What's your context? What are your acceptable trade-offs? In many real-world applications, precise correctness isn't always critical. Sometimes, sacrificing accuracy might be acceptable, and may save on cost and/or complexity. Other times, that's not acceptable. But it's worth considering even these types of non-obvious trade-offs, not just the obvious ones. That's what an expert engineer does: ask the right questions and identify the right trade-offs, and they've become efficient in that process from experience.

An expert sees a problem space as a wide range of trade-off dimensions, including:

  * computational performance
  * memory performance
  * implementation complexity
  * maintenance complexity (understandability)
  * accuracy
  * reusability
  * design time
  * reliability
  * debuggability
  * bug-proneness
  * scalability
  * etc.