Adages
It's increasingly occurred to me, as I get older and crustier, that I find myself saying things to people that I've said a number of times before.
Some of them are well known adages or observations, of course, but others are things that I wasn't previously aware of, or put together from several other pieces, and they've gradually become a sort of collection of my personal adages and laws and maxims.
A few months ago I idly wondered how many of those I actually had, so I started collecting them in a text file. I've come up with more than I expected, so I thought I'd post them in one go for your entertainment.
Simon's Law of Google has frustrated me since at least 2004: if you google repeatedly for something, fail to find it, and then complain about it loudly and publicly, it will only occur to you after you mouth off that the form of words you used to describe the thing in your rant is the one phrase you hadn't already tried typing into Google, and when you do it will work the first time.
The Law of the Easy Bit is another one I actually bothered giving a name to: if there is an easy bit and a hard bit, you'll devote all your concentration to getting the hard bit right, and embarrassingly mess up the easy bit.
The adage ‘Make simple things simple, make difficult things possible’ is of course well known and not mine; Wikiquote attributes it to Alan Kay. My contribution to it is to find numerous occasions to remind people forcefully that the word in the middle should be AND, not OR. (I'm sure everyone has their own favourite example of software, or something else, which signally fails one side of it due to thinking too hard about the other.)
The wording of the next one tends to waver a bit, but a general theme I keep coming back to is: make things either identical, or totally different. All sorts of annoyances arise when things are similar enough to confuse with each other but different enough to make it important not to confuse them, both in the linguistic case of similar words and also more directly functional questions. (For example, this same principle is the reason why big-endian is better.)
Treating your programming language as a puzzle game is a sign that the language isn't powerful enough. This tends to raise eyebrows when I say it, given my history of treating C as a puzzle game, so I often append even if the puzzles are quite fun! I've so far resisted the temptation to try my hand at language design in an attempt to do properly what I've so far only done by trickery, but there's always a chance that sooner or later I'll be hubristic enough to try…
I'm not sure if the next one should be considered one adage, or two that happen to be worded the same: Write the hard part first. The reason I'm unsure is that there are two reasons I say it, and I suspect they might be actually distinct rather than just ends of a spectrum. One reason is that if a task in many parts has one part that's so hard it might actually turn out to be impossible, then attempting that one first means that if it does turn out impossible you haven't wasted lots of time on the easy parts which now have no use. (In particular, this is advice I give to people contemplating writing puzzle games for my collection: write the random game generator first, because if you can't get that to work, there's no use for the UI code at all.) The second reason is that in cases where the easy job is a special case of the hard one rather than complementary to it, it's probably easier and less error-prone to construct a solution for the easy case by simplifying code that solves the general case than to go the other way and try to build a general-case solution by adding bells and whistles to the easy version.
I'm tempted to call the next one the ‘Law of Conservation of Astonishment’, alluding to the Principle of Least Astonishment. This applies to systems (software or whatever) which try to cleverly guess from context what you wanted them to do: the less often they guess wrong, the more painful it is when they do - both because you were expecting it less and are more thrown off-balance, and because the rarer the error the less the system's designers (or anybody else) will have felt obliged to provide tools for coping with it or even understanding it.
On the subject of conservation laws, another thing I often seem to find myself saying is that there isn't a Law of Conservation of Blame. That is, if I can argue that something isn't my fault, that doesn't automatically make it your fault (supposing, that is, that you were the only other person whose fault it might plausibly be), and conversely, if it is my fault, that doesn't necessarily mean it's not also yours!
One that came up just the other day was a thing I use to stop myself agonising forever over decisions: the harder it is to choose, the less it matters. The idea is, if it's hard to decide which of the available options is best, that's probably because they're pretty close to equally good, which means that if you do choose the wrong one you won't lose much.
And finally, here's one that I have yet to work out the best concise wording for, but I'd like one, because I find I have to say it a lot. It's not ‘OK because we're going to do X’ unless you actually do X is perhaps the best I can think of right at the moment. For instance, someone at work will institute a laborious manual procedure (e.g. every time you do some reasonably common thing you must make sure to update three separate wiki pages, a whiteboard and a Word document) and promise that it's only a temporary inconvenience because ‘soon’ the proper automation will come along and then it won't be necessary to do it by hand any more. Of course it never quite does, and next thing you know the hopelessly time-consuming bureaucratic faff becomes enshrined as ‘we've done it this way for years, it can't be that inconvenient, and anyway each of the things you update has someone depending on it who won't want to change’.
Of course, like most adages, these are figurative and/or approximate and/or unproven and/or not universally applicable. The Law of Conservation of Astonishment claims (without evidence beyond anecdote, of course) a negative correlation between frequency and intensity of astonishment, but in order for it to actually keep the average astonishment per unit time constant the relation would have to be exactly reciprocal, and I've no reason to think it is or even any idea of how you could quantify the question. Sometimes it really is necessary to solve an easy special case of a problem before you have the least idea how to tackle the general case; some hard choices do turn out to include one really bad option that wasn't obvious but you could have spotted it with more thought. And it's not impossible that my instinct to write the hard part first may actually be a contributing factor to the Law of the Easy Bit. As with applying any other principle of this level of vagueness, you generally also need the proverbial ‘wisdom to know the difference’.
Also at Dreamwidth. (
comments | Leave a comment )