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.

When you lever your view of code through the fulcrum/razor of DRY then reduction of comments, extraction of methods, replacement of enum/switchs with lookups or polymorphism or callbacks, etc. falls out as a natural consequence.

Likewise, avoiding prefixes like get, test, check, etc.

And also the use of type deduction, i.e., instead of

ClassName a = new ClassName();

prefer

var a = new ClassName();

DRY can be quite a productive line of enquiry.