While those are all good guidelines (though I'm not too sure about 6) a 'master' programmer should probably know when to break each of those rules.
In the end programming is about telling a computer what it ought to do. Making this process as easy as possible is the sign of a good programmer, but there's no reason the process has to be limited to writing code, so talking about what code makes a good programmer seems reductive.
Also in this view 6 is usually a mistake as it makes it harder to communicate, not easier. That said some things don't make sense, and therefore probably shouldn't look like they make sense either.
One of the aspects of mastery (that I've observed in others) is being able to say yes to 99% of requests but knowing how to steer projects away from that one feature that will cause complexity to explode without delivering commensurate value.
In the end programming is about telling a computer what it ought to do. Making this process as easy as possible is the sign of a good programmer, but there's no reason the process has to be limited to writing code, so talking about what code makes a good programmer seems reductive.
Also in this view 6 is usually a mistake as it makes it harder to communicate, not easier. That said some things don't make sense, and therefore probably shouldn't look like they make sense either.