I first tried this while doing a code review many years ago. There was a gratuitous asymmetry in naming between two operations: Attach and Close, IIRC.

I then did most of the rest of the review based on the question of symmetry (although I didn't share that with my colleagues 🙃), looking to improve the symmetry of the code or understanding what the underlying cause of an asymmetry was.

It was surprising how effective and insightful this fulcrum was.

This carried over into some of the subsequent code I wrote. In general it was to favour symmetry, but that was not an assumption.

I approached it as "What would symmetry mean here? What would asymmetry mean here?"

Finding necessary asymmetries also clarified a number of design issues and simplified a lot of interfaces and implementations.

Another guideline I have been testing the boundaries of is DRY. This is not a universal or absolute principle, as some developers think, nor is it simply about duplicated code.

Consider it as an enquiry into the role and necessity or superfluity of repeated information, with a strong skew towards reduction of duplication — whether that is duplication of intent, information, etc.

@kevlin Indeed not. Dry is a very useful principle but far from a universal absolute. Just keeping both test and production code around is a deviation from DRY, when to a large extent one can be generated from the other (or vice versa).

We do it because expressing the same thing two ways helps us understand and communicate better and makes it harder to make most.