Since code is primarily for communication between humans, I suppose we should look to the humanities and ask them what good writing is, but therein lay a parallel exercise to one suggested in the article.
I say this often. Code is for people, and the qualities of great code parallel those of great writing: clarity, efficiency, and a sort of profound obviousness and inevitability.
The job of software architects is the role Heidegger ascribes to man when he calls us "shepherds of Being". To understand the world as it is, and find the right abstractions to describe it. To constantly evolve those abstractions toward better ones, clearer ones, to seek out ways to represent things that make solutions seem obvious and inevitable.
A mathematics professor once said to me that as time went by, the definitions in mathematics became more complex while the theorems became simpler. "Why is that?", I asked, and he replied, "It's progress!" This is the sort of progress that the software architect seeks as well: to set up the problem so excellently that the solutions are smooth and the process is enlightening.
Great writing, and great code, are first and foremost about great ideas. About brilliant ideas that change how you view the world for the better.
Code is primarily for execution. It is very important that it also communicates to people, for the sake of the business that the code supports, but the main thing is the execution.
Not intended to be pedantic or contrarian, but I think this falls apart when the code is making sure a signal is sent somewhere (aka communication). If I write a module that allows IPC am I focusing on execution or communication?
I understand one can say they were “executing the communication” but at that point we ought to remove execute from the phrase if it has to preface anything you do.
To fully disprove my point, at what point do we never execute something with code so the distinction is even worth mentioning?
OP talks about asking humans what good code looks like, and that's the scope of my response. Code as a communication tool between developers is not its primary reason to exist.
Then why do we keep code after it has been compiled to a functional executable? Why do we (those of us working on teams) have rules limiting how code is written, or even in what language? Why do we study abstraction strategies like OOP and FP? Codifying and then storing a solution is not a necessity essential to a solution, it’s a necessity satisfying an external pressure. My conjecture is that that external pressure is the authors’ need to transmit solutions across time (eg to oneself when it stops running for w/e reason) and space (eg to collaborators), so the solution can be read and understood, revised and extended, in the same way we transmit other ideas in natural language prose or other symbolic systems. If we want to treat this outside of the humanities, we need to abandon high level languages like bash and C and return to manipulating registers and memory directly.
