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

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.