Great article, but doesn't address the fundamental issue: defining quality. Other than some objective metrics like code coverage, there is little agreement about what constitutes good code. The closest thing to a consensus might be the rules encoded in linters/formatters. Each Rubocop or eslint rule had to go through code review and public scrutiny to be included and maintained. Most often the rules are customized per project/team. Of course this runs into the same problem the article mentions: narrowness of vision. It seems the only way to achieve a high-minded ideal is the BDFL model of software development.