I'd say the key point is the ability to identify and reason about complexity. Figuring out what the irreducible complexities of a problem are and at what trade

I'd say the key point is the ability to identify and reason about complexity. Figuring out what the irreducible complexities of a problem are and at what tradeoffs these complexities could be addressed in different components of an application (including handing them off to the user). A few corollaries of this are: - Masters will write less code, as they will eliminate most of the complexity when there is time for this. - Masters can more easily put the complexity where they want it, having more control over trade-offs between performance, usability, flexibility, etc. - Masters will have an easier time estimating the required work needed to implement a project, as experience gives them a good intuition for what the irreducible complexity of a problem is. - Masters will rarely tell you a "right" solution except for simple problems. Their answer will depend as much on your specific requirements as the problem you're trying to solve[1]. - Masters will often fix problems by simplifying code. Refactoring will be a natural part to their coding workflow, not a separate "housekeeping" activity. - Those who hide complexity behind more complexity are not masters. Those who always fix problems by adding more code are not masters. [1] It could be argued that "add to numbers and do it fast" is a single problem and that's not wrong. Requirements like "speed" and "usability" are really just another aspect of the desired outcome of a program, but it's rarely thought of as part of the problem to be solved, thus I am considering these constrains as separate from the "core" of the problem.