The happy-go-lucky secretgeek, whose humor I have a particular yen for, has just posted The Better You Program, The Worse You Communicate (4 reasons why), and I was sufficiently tickled to respond in kind. I too am well aquainted with the horrors of human communication, and will admit to portraying a wide variety of the symptoms he mentions (“But I told you about this five years ago!”). And yet, I say: There’s a difference between coding and programming.
Coding, if you will, is human-code interaction; it’s translating a problem into “Turing Space”. This is what secretgeek’s post is about; but Programming, you see, is something else – especially Great Programming. Allow me to illustrate, in bullet form:
1. Programmers mostly communicate with themselves and with other programmers, not with programs.
2. Good programs are sensible.
3. Reviewing code is paramount to listening.
4. Programs don’t mean what they say.
And in detail:
1. Programmers mostly communicate with themselves and with other programmers, not with programs
This is my main point, and all other points derive from it. It is true that when you first learn to code, all you can think about is the mechanics – functions, exceptions, classes, variables and the like; you think in terms of definitions and iterations, and that’s also how you perceive D.R.Y. But pretty soon you get the hang of it, and your mind turns to other things: namely, to what can we may call Design.
Now, some people remain coders for the rest of their lives. You give them pseudo-code, and they translate it to the language of choice. But most programmers, and certainly Great Programmers, ascend to designers after only a few months of programming.
By design I mean that it’s no longer the simple matter of making something work – it’s about solving a human problem using computerized means, and it’s about solving it in the best way. If D.R.Y was a cut-and-dry term, you could just run a text parser on your entire code, and it’d create your functions for you; but it isn’t, because the basis of D.R.Y is that it makes sense, which brings me to the next point.
2. Good programs are sensible.
When you define a class, you do it sensibly. It isn’t just ordinary people who have trouble with definitions, it’s programmers too. If a definition doesn’t make sense, it becomes impossible to remember it for any length of time if it doesn’t make sense. Even if you were able to memorize it, you can’t really apply it to anything if you don’t understand it, since interactions between different elements of any two definitions soon become too complex. Sure, programmers have a far better retention capacity for definitions than most people, as do mathematicians, but as any Great Programmer will tell you, you only use this ability for learning periods and specific calculations.
What i’m really saying is that programmers don’t just define things and get it over with- they define sensible entities. The ontology of the program has to have a zeitgeist, otherwise no one (not even you, if you review your code two months later) will be able to make sense of it.
D.R.Y is about creating sensible sub-operations. Functions, classes, variables, all have to form a coherent unit for it to be considered Good Programming. In other words, black boxes have to have definite meaning.
A corollary to 2 is that if you’re a good programmer, you’re pretty good at taking a complex scenario and breaking it into smaller pieces which are easily explained; and you’re also pretty good at the reverse, which is finding how a many pieces make sense as a single unit. Another corollary is 3:
3. Reviewing code is paramount to listening.
Consider reading someone else’s code. What you’re trying to do is to make sense of it, to find the general idea behind it. If it’s bad code, the uniting scheme will be botched and croocked, ducktape visible and scaffolds creaking. If it’s good code, it will lend itself easily to interpretation, so that you can guess what certain parts of the code do without even reading them.
When you’re reading code, you’re listening. You’re trying to understand the ontology of a new and unfamiliar world, you’re trying to understand how certain entities are used (because, like in language, entities get their meaning by how they’re used, not by how they are defined or operated), repeatedly asking yourself what is the raison-d’etre of each part and all parts as a whole. At times, you’ll focus on a particular snippet, but most of the time you’ll be busy trying to understand how parts fit in a context. All this is very similar to listening to another human being.
A friend of mine talks, I listen. He has his own ontology, his own use of each word and sentence structure. Everything he says is steeped in a framework of general schemes and ideas he holds. He is, in fact, trying to write a “program” which means what he says. When I try to understand what each sentence means, I’m really trying to understand how it pertains to everything else he says, and what is his reason for saying it was – which is exactly what I do when I read each line of code. In short, I am reviewing the conversation program which my friend has written. If i’m a good programmer, a good reviewer of code, then i’m a good listener.
This has the following (somewhat antisocial) implication: the reason we get so angry at what people say is that they write bad code. That is, their ontology (classes, functions) is all mixed up, their logic is flawed (bugs), and their general reasoning is nonexistent – that is, the program doesn’t make sense, it’s just a conglomerate of messy ideas. I’m not saying that this is the case, i’m just saying… no, actually that’s exactly what i’m saying.
4. Programs don’t mean what they say.
Now this next point is a little more subtle: In true spirit of the Philosophy of Language, I claim that no line of code has any meaning outside of context.
For example, the line counter++ really has no meaning if we don’t know what “counter” means, and we only know that if we look at all instances of “counter” in our program. But even that’s not enough, because to know what “counter” really means we have to know why it’s there, and how it’s used – for example, “counter” means the variable which is used to access an array, which is more generally used to fill out the array with default values, which is more generally used… etc.
It’s the same in human conversation.
What this means is that programs don’t mean what they say any more than sentences mean what they say. The line “count++” doesn’t mean what it says, because it says so little. Sure, you can tell that “All men are mortal” begets “Canadians are mortal”, but other than such simple transformations you really can’t say anything without the bigger picture. To get the meaning of a program you have to listen carefully, you have to “tune in”. If it’s well written, interpreting meaning is a breeze. If it’s poorly written, you’ll have trouble, and it may even be so incredibly FUBARed that it doesn’t mean anything at all. But if you’re a Great Programmer, everything, even bad code, is just a little bit easier to get.
Oh, and you know why brevity doesn’t work with people? it’s because they can’t re-read what you said, as they can with an obscure line of code. When you read someone else’s code, you can go over certain parts a dozen times before you understand them, usually skipping forwards and backwards, because the entire code is right infront of you. But spoken language is linear, so each line disappears after its uttered. Don’t expect others to get what you said after only one iteration.
So please, I implore you
Start speaking clearly and to the point
Start making definitions, because otherwise no one will ever get what you mean. Strive to make your definitions as sensible and simple as possible.
Learn to understand poorly spoken programs
But also start correcting those who use obfuscated ontologies and poorly designed ideas
Let people be people, as you sometimes have to let bad code be bad code. Yet deny not its awfullness, and do your best to correct it, gently and without anger.
Be a compassionate speaker, a compassionate listener. Embrace the ‘all too human’ aspects of the strange bipeds you interact with. Try to improve everything you touch.
In short: Speak Good Code.
[...] Why People Speak Bad Code at Kilterish’s Blog [...]