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.
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.