Failure

I was actually part of the way through writing a post but I ran over my deadline. I resolved in my last failure to be much more picky about declaring failures as soon as they happen, even if I could probably get away with it. This is part of my defence in depth strategy: minor failures are fine as long as you handle them, but failures in the failure-handling system are not okay.

So what happened this time? I ended up overstretched because my prototypes got a bit out of hand this week. I set myself the goal of doing very small prototypes, but I got really excited by a few of them and ran over time. Fitting that extra time in with the rest of my work was too much and I ended up tired and overstretched. So the proximate cause is the prototypes taking too long.

However, the root cause is all too familiar: I could have recognised the prototypes taking too long, but instead of correcting that minor failure I ignored it. There was a failure in the failure-handling system, and that allowed the minor errors to accrete to the point where they turned into a major one. So I think it's just a matter of diligence, and resisting the urge to gloss over small problems even when it's convenient.

I'm going to build that habit starting with this post, where I failed, but probably only by 15 minutes. Still a failure, though, and still something I can learn from.

Fibonacci's Infinite Sequence

In software, it's fairly common to see recursive acronyms. That is, an acronym that uses its own name in its definition. The classic example is GNU, which stands for "GNU's Not Unix"... which stands for "GNU's Not Unix's Not Unix". In theory, you could keep expanding it forever, like so:

An even earlier example were the pair of editors called EINE and ZWEI. EINE was based on the Emacs editor, and so obviously stood for "EINE Is Not Emacs". ZWEI was the successor to EINE, and so received the name "ZWEI Was EINE Initially". This is a more complex recursive acronym, which you can explore below:

This recursive acryonm has a pleasingly regular pattern. The number of ZWEIs stays the same. The number of EINEs increases by 1 each time. But what about the number of Emacses? That seems to grow even faster. Let's add a counter (and an auto-expander to spare our poor wrists):

1, 3, 6, 10, 15? Those are the triangular numbers! To my knowledge, nobody else has noticed that you can generate the triangular numbers by counting the number of times ZWEI's acronym mentions Emacs before. I admit the practical applications of this may be somewhat limited, but what an interesting find! Here's a more compact version:

Can we do anything else fun with recursive acronyms? It sure seems that way. I spent some time shuffling characters around and figured out an acronym (kinda) called Fibonacci's I S. "I" stands for "Infinite S", and "S" stands for "Sequence of I S". It looks like this:

And a more compact version. That S/I number looks awfully familiar:

After messing around with these for a little while I discovered they are called L-systems, and they can be used to make all sorts of interesting fractals and things. They were invented to model the growth of algae and other simple organisms, and not to calculate number sequences from the recursive acronyms of software programs.

Just goes to show you that there can be a surprising amount of depth in silly things if you chase them down far enough. You can find the code I used for the above demonstrations on GitHub, and a standalone demo on my demoserver.

Time dilation

Nobody thinks that movies are realistic; they're storytelling instruments that present a more exceptional, more glamorous, more action-filled and more important version of life. But what is it exactly that requires movies to be unrealistic? Or, to put it another way, if we wanted to make the most realistic movie, what could we get rid of before the movie became unwatchable?

Take away the spectacular settings and you've still got all the realistic drama and comedy. Take away the significance of the situations and the word-perfect wit and snappy dialogue, and you've got reality TV. Take away the direction and control over the narrative and you've got a documentary. You can keep cutting and cutting and you still seem to have a viable medium. The one thing you can't cut, though, is cutting itself. Editing. Selecting the important parts and leaving the rest.

I think you could take anyone's life and just cut out all the parts where nothing happens, and you would get a pretty interesting movie. In fact, there have been some fairly successful variations on that idea. On the other hand, imagine a regular movie with all the boring parts put back in. The establishing scene where the lead character has a boring job and quits could take years! When the down-and-out boxer has to train up for the big fight you'd just be watching the same workouts for months and months.

Perhaps one of the most harmful things about our otherwise excellent storytelling culture is that it tends to treat life as a sequence of important things happening one after another. If the protagonist doesn't know what to do and flounders about for years, you just show a few directionless scenes in rapid succession, then cut to when they start to figure it out. But real life is mostly the bits in between the important things, and most of the important things are really consequences of or decisions about all the stuff you do the rest of the time.

Life would really be much easier if we had that kind of instant connection between action and result. If we could decide to learn kung fu, time dilate, and now we know kung fu. Or, better still, decide to follow an idea, time dilate, and discover if it succeeded or failed. Not even for the rewards, just to know if it was a good decision or not. In reality it often takes a long time to find out, and in the mean time you have to just do things hoping that it'll turn out you were right all along. If you're expecting the decision to lead directly to the result, it's pretty surprising to find out that the result actually comes from a series of actions, and the decision is just the first one of those.

So, in the absence of a magical time-dilating remote control, we just have to get used to waiting. But even that is its own kind of sequence-of-important-events thinking. All the in-between bits are when you get to experience the process of what you're doing, rather than just the result. And, since it's going to be the main experience you have, it pays to make the process as enjoyable as possible.

Don't try

The first ground rule is never to worry about remembering, and therefore never to try to remember, because this is a method where the responsibility for you remembering is in the teaching, and not with you. – Michel Thomas

I've heard it said that to succeed you have to try hard. It's not sufficient to merely work at the thing, to do a series of steps diligently or to practice in a particular way, you have to try. But what is trying? In some cases it seems synonymous with doing: "if at first you don't succeed, try, try, try again". That seems pretty sensible. It can also mean to attempt, as in "I don't know, but I'll give it a try", which is a bit wimpy but fine. But it's the last sense, meaning to make a particular effort, to struggle or strain or toil, that I take issue with.

Character attacks are the last refuge of a bad plan. If a poor worker blames their tools, then a poor manager blames their people. When you deal with humans, including yourself, the realities of human behaviour are laws of the universe you work in as much as the laws of physics or economics. It's far too common to see plans that don't take motivation or engagement into account, or assume some kind of infallible superhuman will be the one executing the plan. But, much like machines, people have limitations and failure rates. If that brings your system to its knees, it's not bad people, it's a bad system.

I see trying hard as an early warning sign of that kind of failure. Getting good at something usually takes a long time, and to maintain your efforts through that period takes perseverence, but also takes a very robust system for working. If every day is a struggle then at some point, inevitably, you'll lose at that struggle and then presumably go find something less strugglesome to do. Success might not be easy, sure, but I don't buy that it has to be hard. Maybe in the sense of requiring a lot of work, but not in the sense of working at the edge of your ability.

But we have a culture that seems to paradoxically encourage that kind of brinksmanship. Working hard isn't measured in output or even hours spent, but in suffering. "Ugh, I spent all weekend fixing up our servers." – "Oh yeah? Well, I missed my kid's birthday for an emergency investor crisis." – "That's nothing, I got divorced and became an alcoholic just getting our product to launch." Damn, that's some hard work right there. Coming in and getting things done with no fanfare doesn't seem as impressive, but the endgame of competence is that it starts to look easy.

Instead of trying, I propose building systems you can trust, and then trusting them. If you know it's going to take four hours of sustained effort every day for the next decade to get good, then what's there to try at? Just do the hours. If you know you won't do the hours without timetabling them, then do that. If you know you'll lose motivation when you start to plateau, then come up with some cumulative effort trick or something. Go meta. Build defence in depth.

Just keep improving the system until it stops failing. And if you find yourself trying hard, recognise it for what it is: a stopgap covering up flaws in your system. Fix the system. Trust the system. Don't try.

Chaining

I wrote before about decision hoisting, the process of taking the consequences at an implementation level and hoisting them back up into the high-level decision. Decision hoisting is the antidote to those difficult situations where someone asks you to do different things at different times that conflict with each other. Beyond its role in dealing with others, though, I think it can be a useful technique for yourself.

It's all too easy to make decisions that don't actually further your goals, and one way that happens is just ignoring the consequences as you make the decision. You had a plan to get up early and do some work in the morning, but morning rolls around and you're pretty tired. It starts to seem like a better idea to get a bit of extra sleep, and the details of that plan seem pretty distant. After all, it's not like anything is going to catch fire, you'll just have a little less time in the morning...

Of course, before you know it, your morning's gone and you haven't got the work done. But the thing is, the night before you predicted exactly this situation. You considered it and calculated the relationship between getting up early and getting work done in the morning. Nothing changed about that situation, just your own perspective shifted and, as it did, you lost sight of the connection between the decision and the consequences. Exactly the problem that decision hoisting is designed to solve.

So how do you hoist your own decisions? I've been thinking about a technique I call chaining, where you tie the decision and consequences together via some kind of immediate representation of that relationship. For example, you write "I will only get my work done in the morning if I get up by 8am" on an index card or a piece of paper and leave it by your alarm. When you get up in the morning, you still have the option to sleep longer, but you have to tear up that card before you do. You have chained the consequences to the decision, kind of like a protester chaining themselves to a tree. "You'll have to get through me first!"

I think it's important to maintain the option to go back on your decisions. New information can come up, your thinking can change, or the decision could just have been a bad decision in the first place. But to re-make the decision you need to re-consider the information that went into it in the first place, and that tends to be difficult in the heat of the moment. By representing consequences in a way that forces you to engage with them, I think it's possible to hoist your own decisions and force yourself to make them well, even in difficult circumstances.