Beware of the Train

I hate making decisions. And I'm right to do so, as the emerging body of evidence on decision fatigue makes clear. But sometimes you have to make a decision in situations where there's no obviously good choice: sometimes the differences between options are trivial, sometimes the differences are significant but the advantages and disadvantages are finely balanced, and sometimes you just don't have enough information to assess what those advantages and disadvantages are, but need to make a decision anyway so you can move on.

Some people advocate rolling a die or tossing a coin in this situation. These people are clearly less indecisive than me. Some people advocate tossing a coin, and if you catch yourself thinking "dammit, the other option would have let me do X" then you have discovered your hidden underlying preference and can go for that one. These people are also clearly less indecisive than me: I do that every time. Finely-balanced advantages and disadvantages; if there were no opportunity cost, there would be no decision to be made.

However, I have discovered a procedure that allows me to deal with many of these situations, and to do so quickly and with minimal stress. If you can't find a good argument for choosing one option over the others, look for a stupid reason instead. And do so in a consistent and general way, to minimise the mental effort required. The short version of my system is

1. Pick the red one.
2. If that doesn't work, pick the one with more cats.
3. If that doesn't work, pick the one with more dogs.
4. Give up.

The more detailed version is

1. Eliminate all choices that are less than maximally red. Red, of course, is the Best Colour.
2. If more than one choice remains, eliminate all choices which are less than maximally feline. More cats beat fewer cats, fluffy cats beat smooth cats, cute cats beat ugly cats, kittens beat adult cats.
3. If more than one choice remains, eliminate all choices that are less than maximally canine, subject to the rules above with the obvious formal modification applied.
4. If more than one choice remains, it is officially Too Hard and you are entitled to give up. Go to the pub and order the beer you haven't had before¹.

This may sound stupid, but inventing this procedure has had a noticeable positive effect on my life. It's quick to run through. It turns angsty and tiring vacillation into either a purely mechanical procedure, or a fun game of inventing reasons why abstract things are red, or catlike, or doglike. It works remarkably often: I can't remember when I last had to invoke Rule 4 (though it has had at least one notable success: see below). Hell, Rule 1 is enough most of the time. And, applied consistently over a long period, it causes my life to fill with things that are red, feline or canine, all of which make me happier.

Q: Which of these two equally cute and fluffy kittens should you pick to take home with you?
A: Mu.

Obviously these advantages are not tied to the specific steps listed above. Feel free to substitute your own favourite colour or animals, or to come up with different steps entirely. But I do recommend inventing a procedure like this one if you also struggle to make decisions.

¹ If there is more than one beer available that you haven't had before, drink them all in left-to-right order.

1. Start tracking my weight and calorie intake again, and get my weight back down to a level where I'm comfortable. I've been very slack on the actual calorie-tracking, but I have lost nearly a stone, and at the moment I'm bobbing along between 11st and about 11st 4lb. It would be nice to be below 11st, but I find I'm actually pretty comfortable at this weight as long as I'm doing enough exercise. So, I count that as a success.

2. Start making (and testing!) regular backups of my data. I'm now backing up my tweets with TweetBackup.com, but other than that I've made no progress on this front. Possibly my real failure was in not making all my NYRs SMART, so they'd all be pass/fail; as it is, I'm going to declare this one not yet successful.

3. Get my Gmail account down to Inbox Zero and keep it there. This one's a resounding success. Took me about a month and a half, IIRC. Next up: Browser Tab Zero.

4. Do some more Stanford online courses. There was a long period at the beginning of the year where they weren't running and we wondered if the Stanford administrators had stepped in and quietly deep-sixed the project, but then they suddenly started up again in March or so. Since then I've done Design and Analysis of Algorithms, which was brilliant; Software Engineering for Software as a Service, which I dropped out of 2/3 of the way through but somehow had amassed enough points to pass anyway; and I'm currently doing Compilers (hard but brilliant) and Human-Computer Interaction, which is way outside my comfort zone and on which I'm struggling. Fundamentals of Pharmacology starts up in a couple of weeks, and Cryptography starts sooner than that, but I don't think I'll be able to do Cryptography before Compilers finishes. Maybe next time they offer it. Anyway, I think this counts as a success.

5. Enter and complete the Meadows Half-Marathon. This was a definite success: I completed the 19.7km course in 1 hour and 37 minutes, and raised over £500 for the Against Malaria Foundation.

6. Enter (and, ideally, complete...) the Lowe Alpine Mountain Marathon. This was last weekend; my partner and I entered the C category. Our course covered 41km, gained 2650m of height, and mostly consisted of bog, large tufts of grass, steep traverses, or all three at once; we completed it in 12 hours and 33 minutes over two days and came 34th out of a hundred or so competitors. I was hoping for a faster time, but I think that's not too bad for a first attempt. Being rained on for the last two hours was no fun at all, but the worst bit was definitely the goddamn midges, which were worse than either of us had ever seen before. The itching's now just about subsided, and we're thinking of entering another one at a less midgey time of year: possibly the Original Mountain Marathon in October or the Highlander Mountain Marathon next April. Apparently the latter has a ceilidh at the mid-camp, presumably in case anyone's feeling too energetic. Anyway, this one's a success.

5/6 - I'm quite pleased with that. And I'm going to add another one (a mid-year resolution, if you will): I notice that my Munro-count currently stands at 136/284 (thanks to an excellent training weekend hiking and rock climbing on Beinn a' Bhuird); I hereby vow to have climbed half the Munros in Scotland by the end of the year. Six more to go; should be doable.

Previously on posts tagged with 'angst' (mostly friendslocked): our hero became depressed, sought help, and is now (mostly) feeling better. Now read on...

John Walker, in his excellent book The Hacker's Diet, distinguishes two approaches to tackling problems, which he calls the Manager's approach and the Engineer's approach. Management is about monitoring and ameliorating chronic problems to keep their symptoms to within an acceptable level; engineering is about solving problems outright. Most difficult problems, he claims, must be tackled using a combination of both approaches.

My problem, which might be summarised as "I became depressed because I suck at my job", has so far responded well to a management approach: leaning on friends, attending CBT workshops, prioritizing exercise, talking to my supervisor about my problems. I'm very grateful to all of you for your support, and to the Glasgow NHS mental health team. Now that I'm feeling a bit more spoonful, it's time to apply the engineer's approach, and suck less at my job.

[A perhaps more honourable alternative would be to find another job at which I wouldn't suck, but that would be fraught with risk, and my current job has much to recommend it. Besides, I'm not sure that such a job exists.]

I have three basic problems:

1. I'm not a good enough programmer;
2. I don't know enough about the problem domain;
3. I am now effectively an experimental scientist, but I don't know anything about experiment design.

On the first point, I'm reasonably happy with the readability of my code, but I'm unhappy with its testability and correctness, and I'm very unhappy with the time it takes me to produce it. I'm frequently struck by analysis paralysis. I've spent most of my programming career working with high-level languages, so I'm not very good at lower-level programming. I think the only solution to this problem is to write (hundreds of) thousands of lines of code, at as low a level as possible.

On the second point: before starting this job, I'd previously worked at a compiler vendor and at a web startup which did some machine-learning; back in high school, I'd done some assembly programming for an embedded system. I'd also done a bit of background reading on compiler theory. It turned out that this was insufficient preparation for a job using machine-learning to improve the state of the art in compilers targetting embedded systems. Astonishing, I know.

There used to be a cute slide in the Edinburgh University first compilers course:



Now, that's true for compiler theory, and it explains why compiler research is still a going concern after sixty years, but it doesn't explain why day-to-day hacking on compilers is hard. For me at least, that's because hacking on compilers is systems programming. You need to know, at least to the level of "understand the basic principles of and can look up the details if needed", about things like addressing modes, instruction set architecture design, executable layout, and calling conventions. Forget the fat guys who know C++ who apparently keep Silicon Valley running; I work with guys who know Verilog and the GNU ld control language.

[Betcha didn't know that the GNU linker embeds a Turing-equivalent programming language :-)]

Now, none of this stuff is especially difficult as far as I can see. But it's a lot of background knowledge to have, and if you lack it then you'll be constantly hitting problems that you lack the mental toolkit to address. So here's what I'm doing about it:

• To address the patchiness of my knowledge about machine-learning, I went to the library and got out a couple of ML textbooks, one of which I've now read. I've also signed up to the free online machine-learning class from Stanford, and, while I was at it, the Introduction to AI class too.
• To address my ignorance of architectural issues, I'm auditing the computer design undergrad course at Edinburgh; when I've finished that, I'll audit the follow-on course in computer architecture. So far it's mostly been the sort of boolean algebra and digital electronics that I learned at my mother's knee, but there's a lot of stuff I don't know later on in the course.
• Linkers are a particular problem for me; I think linker errors are the Universe's way of telling me what it's like for a non-techie who thinks they need to press the "any" key. zeecat kindly lent me a copy of Levine's book Linkers and Loaders, which I am now reading; as an unexpected bonus, one of the early chapters is a 30,000ft tour of computer architecture. To my delight, the book walks you through the construction of a simple linker in Perl.
• To address my lack of C and assembly language experience, to solidify my understanding of basic compiler theory, and to give me a testbed for implementing some optimisation algorithms later on, I started writing a simple compiler in C. Currently it accepts a simple term/factor/expression grammar and outputs x86 assembly; the plan is to extend it so it accepts a subset of C. "Compiler" is currently a bit of a joke; it is technically a compiler, but one that does really aggressive constant folding :-) I haven't hacked on this for a while, because work got in the way, but intend to pick it up again soon.
• To address my ignorance of C minutiae, I started reading through the comp.lang.c FAQ, at Aaron Crane's suggestion. This is also stalled, as is a project to convert said FAQ to a collection of Mnemosyne flashcards.
• The world seems to be standardising on Hadoop as a clustering solution; I should try that out at some point.

So, anything else I should be doing? Anything in that list I should not be doing?

I have no real idea how to start addressing my third problem, namely my ignorance of experimental design. Go to the library and get another book out, I guess. Anyone got any recommendations?

[Created using Dan Awesome's Rage Maker. Gingerbread recipe by Claire MacLeod.]

Yesterday I finally crossed off a to-do item that's been bothering me for twenty-one years.

In Primary 4 I had an evil, horrible, hateful, permanently-angry teacher called Mrs Begg. I have no qualms about giving her real name, and even if I did, she's surely dead now. Mrs Begg had one of those rolling endless blackboards, and up the right-hand side she'd write a list of things to do. As soon as the first child finished the last task on the list, she'd add another one on the bottom. I, of course, was usually struggling along somewhere near the top of the list, not because the tasks were too hard (they weren't) but because the work was mostly boring and the volume of stuff I was supposed to get through was too dismaying.

Then, one day, she pronounced herself more than usually dismayed with the slow kids, and wiped off a bunch of items from the list. Great! you might think. But you'd be wrong, because (a) I'd just been told in no uncertain terms that I'd failed, (b) the list still grew faster than I could keep up, and (c) there were actually some items on the wiped-out portion that I was looking forward to doing. When I got to them. Whenever that would be.

In particular, one of the wiped-out tasks was to make one of those paper fortune teller things. As a result of the Bonfire of the Makework, I never learned how to construct one. I'm sure you can imagine the difficulties that the lack of this crucial skill has caused in my subsequent life.

When I'm under stress, the image of this Sisyphean blackboard comes back to haunt me, and especially the task that I was supposed to complete - that I was looking forward to completing - but didn't. So on Sunday I decided to exorcise it once and for all, by sitting down and making a paper fortune teller. I was going to Google for some instructions, but then wormwood_pearl offered to use her Magical Girl Powers¹ and teach me how to make one. Turns out it's really easy: cut out a square of paper, fold it across both diagonals, open it out again, fold all four corners into the centre to make a square with half the area, fold all four corners of the new square into the centre to make another square with a quarter of the area of the original square, fold this third square in half lengthways, then stick your fingers into the folds. If that's not clear, there are, for the moment, diagrams on the Wikipedia page.

Since I'm a geek, the fortunes had a programming slant. After spelling out your favourite programming language and choosing your favourite regular expression metacharacter, you arrive at one of the following four fortunes:

• Your projects will all come in on time and under budget.
• You will be assailed by numerous heisenbugs.
• You will not write enough tests.
• You will write a subroutine too cleverly, and later regret doing so.

The first outcome, of course, is the Holy Grail (and seen about as often), and the rest are almost inevitable.

The alert or clueful reader will have noticed that there is only one good fortune, and so if the name of the sitter's favourite programming language has the wrong parity they are denied any possibility of a good outcome. This illustrates the important lesson that, though many technologies may be good enough to succeed, a bad initial choice can scupper you entirely. But even if you choose a language with the right parity, you have only a 50% chance of a good outcome: this illustrates the fact that good technology choices are necessary but not sufficient to success - the skill and good taste of the implementing team are still critical. More devilishly, if I know a particular sitter's favourite programming language in advance I can deny them any chance of success (mwahahaha! The power, it is intoxicating) which illustrates the unfortunate truth that even a good team using the best tools is screwed if the client doesn't play ball.

¹ By which she meant the Magical Powers she has by virtue of being a Girl, not the Powers she would have by virtue of being a Magical Girl. If wormwood_pearl is a Magical Girl, I have seen no sign of it. Which is of course exactly what I would expect to see if she were a Magical Girl...

*cue Bubblegum Crisis music*

Number 1 in an occasional series about friends and loved ones who are no longer with us.

My schoolfriend Fred Hood died on Christmas Eve last year, at the age of 28. Swept away by an avalanche while skiing in Austria, he was mercifully killed instantly. Being an international sort of chap, he had memorial services in Washington DC, Bologna, and Eton; I went to the Eton one, and then went back to his parents' house, where we held a wake for him in the marquee that had originally been hired for his brother's engagement party.

At the wake (and this is an idea I am totally stealing if I ever get asked to run one), they had a sort of open-mike eulogy: a microphone was passed around, and anyone who felt like it could stand up and share their memories of Fred. These were mine.

Back in 1997, we did a show called Blood and Honour at the Edinburgh Fringe, in which Fred played the leading man and I played a corpse. Fred was also in a rather better-received show called Who's Laughing Now?, in which he played a school bully. There's a story about Stanislavsky (from Bulgakov's Black Snow), in which Stanislavsky, unhappy with an actor's performance, calls for a bicycle and tells the actor "Now, love that woman on a bicycle!". In a similar spirit, I challenged Fred to sit down on a chair as his character. And he did. For a few seconds, as he thumped down, sprawled proprietorially, cast a hostile, privileged glance around the room, and shook open his newspaper, Fred wasn't inhabiting his body; instead, the space was occupied by an entirely different person, a million miles from the Fred we all knew. It remains one of the best pieces of acting I've ever seen.

Much was made at the service of Fred the actor, Fred the intellectual, Fred the scholar. Rather less was made of Fred the sportsman. And yet, we used to row together in Lower Boats, training six days a week and lifting weights for a couple of hours every Tuesday, Thursday and Saturday. I remember one day, when we went for a training run around one of those Etonian sports pitches named after an ancient Near Eastern civilisation, that Fred and I agreed to pace each other, and not to compete with each other. And yet, when we reached the final straight, I sped up to a sprint and hit the finish line well before him.

I just want to say that I'm sorry, dude. That was a dick move.

On Tuesday night, I met Colin Wright, who's one of the inventors of siteswap notation (like most really good ideas, it was invented independently by at least three groups). He was in town to give a lecture on the mathematics of juggling, which I attended. Excellent lecture, though much more historical than mathematical: still, it was very interesting to hear the early history of siteswap from the horse's mouth! The breakthrough pattern was apparently 5551, whose existence was deduced from the jugglability of 53 and 552 - apparently Wright and his group went to the BJC in 1985 and showed people 5551, and nobody could believe that it really worked. Then they went to the EJC a few months later, and people tried to teach it to them :-)

After the lecture he went to dinner with me and a few other members of the department, which was great fun - he's a really funny, interesting guy (it was him who told me about the Lipson-Shiu test, for instance). And he knows all the words to Tom Lehrer's Elements song (and most of the others, from what I could tell). But he had some rather more serious advice for me: he suggested that I try to write 1000 words of my thesis every day. It doesn't matter if they're good words, or if I throw them away the next day, but I should just try and get them down, so I'm in practice at expressing mathematical ideas on paper.

So that's what I'm going to do. Since Wednesday was the first day of Lent, that seems appropriate: I'm going to try to write 1000 words for every day of Lent, allowing myself one day off per week to go hillwalking or whatever. So far, I've managed 500 plus a diagram on Wednesday, 350 plus another diagram on Thursday, and 300 today - not exactly hitting the target, but my thesis is now at 48 pages, which is five pages longer than it's been for months¹, and I'm feeling considerably less stressed about the whole business. Allowing yourself to write stuff that you're intending to throw away is incredibly liberating.

I'm going to keep posting about this: please prod me if I don't, and remind me to do some bloody work. If anyone particularly wants to be spared these posts, let me know and I'll try to set up a filter or something.

¹ My supervisor says I shouldn't worry too much about page count, because I have a very concise style²: I replied that it was really d(thesis)/dt that I was worried about.

² Years of trying to save paper by answering questions in the smallest space possible, probably. At Oxford, I'd typically hand in one sheet of paper per course per week, unless it was something horrible like fluid dynamics where concision was impossible.

I went to a high school reunion a couple of weeks ago.

( Cut for arrogance )