This is only an opinion --but it's the opinion of someone who has been involved in software engineering since the 1990s:
Since this quote is in the section of general advice, I feel this advice applies mainly to the analysis and design of systems. Here's an example: You want to make a command line program (or it could be an API) that can behave differently, depending on certain conditions. So you have an analysis and design problem, which is: how do you cover these different scenarios (flexibility) without making the program/api too difficult to use (complexity)?
If you hard-code the choices into the system, it gets a part of the job done, but there is no flexibility and so your system will be useless to those who need the outcome to match certain common use cases. But, on the other hand, if you require users to type in a long list of parameters every time they use the system (complexity), users will avoid this solution because it is simply too difficult to use for the most common scenarios.
Symmetry in this sense means striking the right balance among the aspects of usefulness and simplicity so that your system will match the needs of its intended users. In my hypothetical case, the programmer might provide a config file which lists comments showing the default values for the config options. If a user needs to tweak this behavior slightly from the defaults, they can set the config values as it suits them in the config file once, rather than needing to remember to type the overrides in as command-line params each time.
Again -- this is one simple example. When defining a data model (a different realm where symmetry applies), it is common to take many iterations to "get it right" so that the system can properly reflect a real-world problem, such as how to represent that 'many students take many classes at the college'. Early efforts tend to be "asymmetric" in the sense that they fail to capture key relationships between important concepts by making the data model too "flat" or simplistic. Further modeling efforts, though, may make the opposite mistake by trying too hard to faithfully capture every possible corner case, including those which either seldom occur or have no practical value (such as recording whether any instructors took leaves of abscence during a semester, when the point of the system is to capture student attendance and grades).
Since this quote is in the section of general advice, I feel this advice applies mainly to the analysis and design of systems. Here's an example: You want to make a command line program (or it could be an API) that can behave differently, depending on certain conditions. So you have an analysis and design problem, which is: how do you cover these different scenarios (flexibility) without making the program/api too difficult to use (complexity)?
If you hard-code the choices into the system, it gets a part of the job done, but there is no flexibility and so your system will be useless to those who need the outcome to match certain common use cases. But, on the other hand, if you require users to type in a long list of parameters every time they use the system (complexity), users will avoid this solution because it is simply too difficult to use for the most common scenarios.
Symmetry in this sense means striking the right balance among the aspects of usefulness and simplicity so that your system will match the needs of its intended users. In my hypothetical case, the programmer might provide a config file which lists comments showing the default values for the config options. If a user needs to tweak this behavior slightly from the defaults, they can set the config values as it suits them in the config file once, rather than needing to remember to type the overrides in as command-line params each time.
Again -- this is one simple example. When defining a data model (a different realm where symmetry applies), it is common to take many iterations to "get it right" so that the system can properly reflect a real-world problem, such as how to represent that 'many students take many classes at the college'. Early efforts tend to be "asymmetric" in the sense that they fail to capture key relationships between important concepts by making the data model too "flat" or simplistic. Further modeling efforts, though, may make the opposite mistake by trying too hard to faithfully capture every possible corner case, including those which either seldom occur or have no practical value (such as recording whether any instructors took leaves of abscence during a semester, when the point of the system is to capture student attendance and grades).