Somehow, in spite of two posts already full of personal adages of mine, I somehow haven't exhausted my supply of them yet. In the last couple of years I've collected another postful of things that I noticed myself saying a lot and realised I've been saying all along.
A principle I live by, and encourage others to as well, is that you will rarely regret timestamping things. I probably got the idea from computers' tendency to timestamp everything as a matter of course, and having noticed it was useful there, started realising it would be useful everywhere else too. For example, on reminders to yourself (‘2016-05-20 buy milk’) a timestamp provides built-in obsolescence by making it easy to recognise that that was last week's post-it note; in an address book (‘2010 Sophie's phone number’) it makes it easy to remember whether that's the version from before or after somebody moved house; on something being regularly updated (e.g. a note in a DVD case saying which episode you last watched) it confers some protection against occasionally forgetting to update it (‘wait, it says we watched episode 6 the week before last, so actually we must be on 8 now’). So I've tried to get into the habit of timestamping things on general principles, because even if I didn't specifically foresee any of those requirements, it's not uncommon that later on I turn out to be glad I did so anyway.
(In fact I often feel that some more public kinds of thing could usefully be timestamped which aren't. A good example is signs reading ‘NEW ROAD LAYOUT AHEAD’ which have been there for long enough that the sign is beginning to fade…)
In situations where something has been bad for a while, and now it's just starting to crawl back towards being not so bad – good examples are beginning to recover from an illness, or having mostly paid off a debt – I'm fond of telling myself that this is the moment to consolidate, not squander. Let things get well into the black before doing anything that risks making them bad again.
In situations where there's a tradeoff to be made between several desirable things (price versus quality of a product, for example, or time-space tradeoffs in programming), I often notice the phenomenon that nobody can tell you the right tradeoff, but everybody knows the wrong tradeoff when they see it. You look at some particular consumer device / piece of software / service and you can immediately see that it costs too much for what it's offering, or overemphasises learning curve over feature set (or vice versa), or whatever else, and you decide not to go with it; but if challenged to state in advance what tradeoff between those things you would be happy with, it's really very hard to do, and you'll probably find later on that some example case that satisfies whatever you said up front turns out to be unacceptable to you after all. Of course this is kind of frustrating for the people on the other end of the problem: the ones who are trying to make a thing that users are going to reject for making the wrong tradeoff in a way not even they could have reliably predicted. But it's comforting, at the same time, because once you recognise this as Just One Of Those Universal Facts Of Life, you don't have to feel bad about it when it happens to you.
A thing I often find myself wanting to say in arguments – both on and off the Internet – is: that statement is perfectly fine except for the word ‘just’. It seems to be a fairly common phenomenon that someone will make a statement whose first-order content is uncontroversial, but slips in a ‘just’ somewhere to hint that a particular thing mentioned in the sentence is easy or trivial or already agreed on, when it isn't. Typically if the person had spent a whole extra sentence on saying that the thing was easy, someone would have responded ‘No it isn't!’, but somehow, making that sentence implicit in a ‘just’ makes it easier to accidentally let it go unchallenged, which is why I think it's the duty of sensible people everywhere to expose and denounce these unwarranted ‘justs’ wherever they occur.
Here's a thing I've said to myself a zillion times, but I don't recall having ever uttered it to anyone other than me before: it's not a proper plan until it includes a way of not forgetting each step. I often say this to myself as a means of distinguishing the mental state of ‘wouldn't it be nice if’ from the state of ‘right, I actually intend to do this thing’, and to remind myself that if I haven't set up enough reminders to make the plan actually happen, it might just as well still be in the WIBNI category for practical purposes. But it applies just as well outside my own head – the number of times I've sat in meetings at work, for example, and we agree that we want to do a thing but nobody arranges any way for it to get done suggests that perhaps I should start shouting this one everywhere!
There's no rule in these posts that says I can't intersperse general-purpose life advice with massively specific technical topics, so here's something in the latter category: in a compiler with N phases, there are N² phase-order problems. (This can occasionally apply to things other than compilers, and perhaps it might even apply to things other than software, but I haven't thought of any examples of the latter yet.) For the non-compiler-literate, the point is that if you're trying to do a very complicated transformation by breaking it up into lots of individually simple sub-phases, there is an unavoidable echo of the original complexity lurking in the question of what order you do those phases in – and often you find that there is no right order, and no matter which way round you do two things, some case will be missed. And the more and smaller the phases, the more that phase-ordering difficulty grows and grows, until it can easily feel as if it's become the biggest source of bugs and problems.
Of course, I'm not really saying that it's a bad idea to structure a complicated thing like a compiler in the form of many small and individually comprehensible phases rather than a few monolithic and impenetrable ones; I think the design tradeoff almost certainly does still work out in favour of the many-small-phases approach. I just think that it's often worth pointing out that it is a tradeoff, not a no-brainer, and it does have a downside of its own – and not only that, but it's a downside you can expect to stub your toe on on a fairly regular basis and that shouldn't be surprising.
A more general software engineering one: test suites are not just for running stuff and printing ‘OK’. I deal with too many test suites which have forgotten the second duty of a test suite: if a test fails, provide details. Specifically, provide enough detail for the failing step to be identified, and then for it to be re-run outside the test automation. If the first thing I have to do is to run the test script under a debugger just to extract the command line of the program under test which I really wanted to debug, then the test system is not doing a good job of making my life easier!
And still on the software topic, but considerably more frivolous: internal web apps we use inside my company (not to mention all the horror stories I hear about similar things in other companies) have made me fonder and fonder of saying that it's called ‘enterprise software’ because every few episodes you have to eject the warp core. These days I feel as if I'm only half joking when I say that!
Back to non-computing topics, here's a sentiment that I've expressed a few times in different words, and now I've come up with a snappy short phrasing, so it's a newly minted adage: if you think you're getting mixed signals, they may well really be noise. This can come up in a wide range of contexts, from hint-based social interaction (e.g. flirting) to technical situations such as trying to debug something on limited information. And at both ends of that range, I've been bitten enough times by spending ages overthinking what could possibly be meant by some series of apparently contradictory indications – and eventually finding, of course, that the answer was ‘nothing at all’ – that it now tends to be my instinct to look at any confusingly mixed signal and consider that possibility first.
Another one that I've only just come up with a good phrasing for: don't make premature tradeoffs. This describes a particular class of engineering laziness (software or otherwise), in which somebody has found a way to solve a problem X, but unfortunately it causes some undesirable side effect Y – and immediately begins to ponder the question of which of X and Y is worse, so as to decide whether or not to put the suggested solution into effect. And the tradeoff is ‘premature’ if you jump straight into that mindset before even trying to compensate for the side effect, or find a different solution that avoids the side effect, or detect more cleverly when the solution should be used in any given case, or at any rate somehow trying to find a way to get the best of both worlds. Of course sometimes that won't be possible, and you will have to decide on your choice of tradeoff after all, but I often feel that people jump to that position without giving adequate thought to whether there's any third option.
The next one I still haven't really come up with a perfect wording for, so I think I'll just have to go with a good-enough one: often a relationship between two things is monotonic, but not the way round you expect. Perhaps this most commonly comes up in strategic decisions of the form ‘how much X should I allocate to two Y if one works better than the other?’ – of which concrete examples might be ‘should I work on practising my weaker skills or on further improving my strengths?’, or ‘should I work extra hard as compensation on days when I'm half asleep, or save it to make the most of the days when I'm on a roll?’. Often in these situations it's obvious from the start that there will be a monotonic relationship between the two variables, but it can often be counterintuitive which way the relationship goes.
Also on the subject of monotonicity, here's one that often seems to save me time while I'm trying to make a decision: given two factors that are influencing my decision, if they point the same way, I don't have to work out which is more important. You only have to care about whether X is more important to you than Y if you can't have both, or if you have to trade off how much of each one you can have. If the choice is between both and neither, that's a big pile of introspection you can save yourself having to bother with! (Seems obvious, put that way, but I've seen people get bogged down in trying to work it out regardless…)
A slightly silly one that recurred in a couple of contexts recently: medium-difficulty things are the hardest. This happens because once a thing gets beyond a certain level of difficulty, you have no choice but to resort to some kind of very powerful or highly general solution technique; and once you've brought in that big gun, it makes your problem (and many other problems) look easy. But when your problem is of the size one smaller than the one where you'd resort to the big gun, it's more tempting to solve it by hand or using less powerful (particularly, less expensive) techniques – and that is the hardest kind of problem you'll ever have to solve by yourself. (An example of this is that cyclists are more affected by hills and headwinds than either pedestrians or motorists, because they're going at the highest speed for which you don't have to resort to an external power source.)
Finally, here's a ‘Special Guest Adage’, which isn't my own at all, but after hearing it once, I took it utterly to heart: time spent in reconnaissance is rarely wasted. The internet attributes it to several different military officers throughout history, but of course as a thoroughly unmilitary person I interpret it in various other senses. For a start, the purely literal sense is useful even if you're not a soldier – when I'm going to go somewhere I don't already know well, I'll often take the opportunity to make a previous trip there when I'm not in such a hurry. (Or, even more so, if I can arrange to have visited a place before in daylight, it'll be easier to find my way round when I have to go there in the dark one evening.) But also I think the same sentiment is true when the ‘reconnaissance’ is entirely metaphorical: for example, in software, I often find it worthwhile to try to implement a tricky idea, even if I think there's not much chance of it working, because even if it doesn't work, you still got a load of practice at general technique and some specific learning experiences from that problem. Of course this doesn't completely stop me from feeling bad on the day I find out that the thing didn't work, but I think it at least helps me get over it a bit faster!
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
no subject
NEW ROAD LAYOUT AHEAD
Test suites
no subject
A thing I have to tell developers who are new to banking, over and over:
Never give a trader a price without a currency, a timestamp, and a source.
The aphorism I would add to Simon's List (capitalised) is:
"Make sure your baby learns to play well with other children".
I'm an end user developer, and everything I do has to work on a busy desktop, not seize resources needed by the other processes, exchange data with other end user applications, and provide interfaces that work for users, managers, system administrators and support staff, and documented APIs allowing other developers to extend and adapt my work.
A large part of all the hours I have ever worked, is working around or against applications that do these things badly or not at all: no software, anywhere, gets to work in splendid isolation in a universe of its own, but half the sofware ever written is implemented as if it did.
no subject
"New road layout", I'm also often annoyed at the way this is done. But OTOH, I guess in practice "put the sign up and leave it up" works ok, because people who drive the route regularly know the sign isn't *new*, and people who don't know the route recently will either benefit from the sign (even if it's years later) or not know the area at all and not mind whether it's changed or not.
The "just" thing really annoys me, especially that the statement often has much the same factual content but completely opposite import. Saying, "if you want X, just do Y" implies it's easy and we shouldn't worry about it much, whereas usually Y looks superficially easy (e.g. "stop putting cigarettes in your mouth and lighting them") but is actually really hard.
no subject
Happy birthday *hugs* xx
no subject