The messenger


Charlton Heston: Damn it, George! You just don't get it. Guns don't kill people.
George W. Bush: They don't?
Charlton Heston: No! Bullets do! Guns just get 'em going really really fast!
That's My Bush

I think one of the most abused words when talking about motivation or productivity is "procrastination". I was pleased to learn that it's not as commonly used in the rationality community, until I found out about akrasia, a greek word for acting against your own interests, which is basically used as a synonym. It's not that these words aren't useful or meaningful. It's just that, like death, depression, or cancer, they represent an entire category of problems as one big problem. That big problem tends to absorb attention and makes it harder to think about and solve the little problems that constitute it.

I've heard this idea referred to as a semantic stop sign: "Why didn't you finish this?" "Procrastination!" "Oh, okay". Every kind of motivational failure ends in procrastination! We're not satisfied with hearing that someone died because their blood stopped circulating, even though it's true in the vast majority of cases. We want to know what led up to it: their blood stopped circulating because they stopped breathing, because of massive trauma to the chest, because they hit the ground really hard, because they jumped out of a plane and their parachute didn't open. The situation merits a lot of analysis if you let it. Indeed, there's no reason to stop there. Why did they jump out of the plane? Why didn't their parachute open?

This process is sometimes called the 5 whys technique, though obviously the number 5 is pretty arbitrary and these days most people just say root cause analysis. Of course, root cause is a bit of a nebulous concept as well. You could keep running on this until you get answers like "because humans evolved in small social groups", or "because the fine structure constant is approximately 1/137". So it's definitely possible to go too meta when looking for a root cause, and you see this most often in the "society is to blame" genre of explanations, On the other hand, it's probably more common to not go far enough.

The real issue is that determining the cause of something is an essentially political exercise. People often have particular things that they would rather not consider. So the reason you're overweight is definitely not the proximate cause of eating too much, it's a distant cause like genetics or GMO foods or alkalinity or whatever. On the other hand, there are particular things that it is expedient to believe in because they fit our expectations. So if you believe that willpower is the most important thing, you'll stop as soon as you reach a willpower-related explanation for a problem. If you believe that you're suffering from a terrible disease called akrasia, that's where your search for the cause for a missed deadline will land.

Sometimes, as in this last case, it can lead to particularly distorted thinking because it hits you right in the insecurity. If you're trying something new and you're not sure it'll work, or if it's outside the status quo in some way, it'll be a lightning rod for anything that goes wrong. You have a few bad days and your new side project goes to shit. "I knew it!" you say, "this side project was never going to work". In reality, the problem is that your crappy day job is hugely draining your motivation. The failing side project was actually a helpful messenger coming to tell you about a problem you could fix, and you went and shot it because you were already convinced it was going to be the problem.

Of course, it could be the other way around: if you're convinced your main job is a problem, maybe you'll blame it for a doomed side project. When I say "essentially political", I mean that there are lots of different options for causes, and you're free to pick between them on whatever basis you choose. It's true that in a different society we wouldn't have as many murderers, and also true that if you took away the guns, they wouldn't kill so much, and also true that you could just control bullets instead. Hell, we could breed people with thicker ribcages. The point is that anything is a cause if it being different would have prevented the effect.

So as far as which is the true cause, I think there's no such thing. Rather, I would say: which are the useful causes? Society might be responsible, but it's pretty difficult to change. As is human sternal strength. You want the causes that act as the best levers for you to manipulate to get the change in effect you want. And for that it's important to evaluate the causes rationally: not to get fixated on one particular cause, ignore causes that are uncomfortable, or let your expectations tell you the cause before you've had a chance to figure it out for yourself.

The tree planter's paradox

The best time to plant a tree was 20 years ago. The second-best time is now.
Proverb
That doesn't make any sense. The second-best time is one instant after 20 years ago.
Unknown

I've been trying to figure out where I heard that second quote, but I just can't track it down. Thing is, whoever said it has a point. The proverb really relies on two opposing definitions of "best time" which, while it makes for a pithy quote, actually masks a more fundamental point that I think is worth investigating. "The best time to plant a tree was 20 years ago" means best time as in the time when it would have the most beneficial impact on you. On the other hand, "The second-best time is now" uses best time to mean the time you have the most impact on it. Viewed that way, the problem in the second quote disappears. It's clear that "second-best time" is really a misnomer; 20 years ago and now are both the best time, but for different things.

I think of these opposite kinds of best together as the tree planter's paradox. Simply, at the time when your decisions have the most impact, the consequences matter least and vice versa. Twenty years ago, planting a tree or not planting a tree had basically no impact on your life. Either way the consequences were twenty years away. But now, today, the day when you have finally accepted dendrology into your heart and desperately need a tree right now to prove your devotion? Nothing you do can bring one into existence. The moment when the consequences matter the most, your decisions have no importance at all.

It doesn't have to be a long time, necessarily. The best time to order food was before you got hungry. By ordering food after you get hungry, you're always condemned to a certain amount of hunger while you wait. The best time to fix a problem in a relationship was before you realised anything was wrong, because by the time you realise it the damage is already done. The best time to learn from a mistake was before you made it. Unfortunately, it's pretty hard to know about a mistake before you make it, and you can't go back, so you have to settle for whatever you can do now. Any time your decisions are separated from their consequences, the decisions peak at the start and the consequences peak at the end.

This is a pretty compelling reason to reduce the distance between action and consequence when you can. Unfortunately, that only goes so far, and ultimately there's always going to be a gap. I wrote a while back about short-term and long-term thinking, and wondered why it's necessary to work so hard to build connections between the two. Perhaps the tree planter's paradox is the reason. Long-term thinking is the way to have the biggest impact, but like it or not the short term is where we actually live. Our experiences happen now, our decisions happen now, and our evolution has tuned us to be highly effective now-optimisers.

All the more reason to find ways to subvert our nowish nature and find ways to bring the consequences of the future into the decisions of the present. The trees are counting on us.

Letting the genie out

I walk in and sit down. "Hi", she says, "thanks for coming in. Why did you decide to do a voice training course?"

"I, uh, I'm interested in podcasting." This isn't really true. Mostly I'm here because I was talking to a friend about how radio people had such great voices. Were they born or made?

I had a theory: surely they must do some kind of special voice training. And if they could do it, so could I. I looked it up. I was right. I felt like Mendeleev predicting the existence of germanium. And now I had to do the course.

"Great", she says, "now read this", and hands me a piece of paper with a radio script on it.

"Right now?"

"Whenever you're ready", she says, pressing the record button.


Weirdly, I've had this experience several times when learning new things. Singing teachers expect you to just sing on command. Music teachers want you to just play the instrument for them. It's like they have no respect for the magic and deep significance of what you're doing. No special run up. No fanfare. Just, okay, read this. Now stop. Now read it again differently.

The first lesson in that course was me reading something I'd never looked at before to a room of 20 people, all listening and taking notes. Every lesson we did it again, until somewhere along the way it stopped seeming like a big deal. And if I think about the things I'm best at, they all have this same quality: no magic, just get on with it.

I wrote a while back about waiting for The Call, that yearning for someone important to come along and tell you "now's the time, go do the thing". Before that I wrote that success is imaginary: it's something that you feel second-hand when you see successful people, but first-hand success doesn't feel the same way. I think there's a similar effect at work here.

When you see someone do something really impressive, it's like magic – for you. For them it's work. That guy flipping his bike off Edinburgh Castle might look like he's working up to it, but that dramatic pause is for you, not for him. He can probably flip a bike in his sleep.

Something like that doesn't take magic, it takes practice. Waiting for inspiration, working yourself up to it, trying to summon the genie of creativity, these are all marks of someone who wants to be on stage, but still thinks of themselves as the audience. When you're a sausage maker you don't get the tasty rookworst, you get to grind up pig bits. When you're a professional singer, you don't get to feel like singing is still a special event. It's your job, you just do it.

I think that letting go of the specialness is a crucial, if tragic, part of creation as a process. When everything you make is a heartbreaking work of staggering genius, what room is there for the procedural drudgery of self-improvement? What room is there for taking today's special snowflake and tearing it to shreds so you can build a better one tomorrow?

Maybe you won't dare. Maybe the allure of being special is too strong, and you stay home rather than give the most heartfelt and powerful radio narration of your life, a reading for the ages, with a voice that could shake the heavens themselves and make angels weep, only to be told "fine but too fast".

Nobody improves without laying their magic bare.

Real Life vs Internet

People standing around the finished product

This is a write-up for Real Life vs Internet, a project I just finished for the UNSW Artsweek. The brief was in some way to bring the concept of liking things on Facebook into the real world. I quite liked the absurdity of it: in real life you can like stuff just by enjoying it, but on Facebook you do it by clicking a button. Can we bring button-pressing-as-affection to the physical world?

I proposed we go one step further and see which people would click more: an internet Like button or a real-life Like button. This would involve building two parallel systems: one online and one physical, both updating in real time. Like many university-related things, the timeline was pretty short: in this case, about a week from concept to finished product, of which 4 days was building the thing.

The first thing we needed was to figure out the hardware. I was most nervous about this because I'm not super electronicsy (occasional Shenzhen binges notwithstanding) and I was worried I'd get in over my head with wiring or not enough capacitors or whatever. I spent a long time daydreaming about a fully mechanical counter before I bit the bullet and decided to go full electronic.

I owe a debt to the enormous DIY maker scene, because prebuilt LED panels are expensive and driving 10x7 segments (= 70 wires) sounds like no fun at all. Thankfully Sparkfun sells a big 7-segment display and a chainable control board designed to solder on to the back of it with a shift register that lets you turn those 70 wires into 6.

The other hardware question was how I was going to drive this thing and get it hooked up to the internet. An Arduino was a no-brainer for driving it, especially since Sparkfun had fairly detailed instructions with sample Arduino code. I'm sure I could have figured it out from scratch on another platform but this seemed like the path of least resistance.

Then I needed to get the Arduino connected to wifi. I'd previously used ESP8266 chips, and that seemed like the way to go here. I was originally intending to wire the ESP to the Arduino manually, but in the interests of expediency I grabbed a plug-and-play ESP Shield from Jaycar. The thing had no documentation but it was basically fine once I managed to flash it to the nifty NodeMCU firmware.

Arduino, ESP, and bluetooth serial adapter attached together

The last step was to figure out how all the wiring was going to work. I knew I'd want two separate runs of panels (one for real life, one for internet), and that they might be some distance from the central logic board, but I didn't know exactly where. Also, this was going to be an outdoor installation, and I wanted the electronics to stay fairly isolated from everything else in case of damp.

After dithering on this for a while, I eventually decided to use cat6 network cables. They're neat and modular, and some investigating suggested that the wire gauge of cat6 is thick enough that they wouldn't waste a lot of current or melt. I even found these neat-if-overpriced keystone jacks designed for wall sockets, but also worked pretty well as wire breakouts. I put everything in a faux-tupperware clippy plastic lunchbox and dremeled the holes I needed.

The lunchbox of power

While I was doing this, my co-conspirator (and Artsweek coordinator) Jeeves was building the physical panelling. This was basically a pair of large boxes with mounting windows for the digit displays, as well as a big button made from some springs and lengths of plumbing pipe. I don't know if there's a place where you can buy giant buttons off the shelf, but we couldn't find one and the macguyver plumbing pipe monstrosity worked surprisingly well.

We ended up putting all the control hardware inside the lower box and running one of the network cables up into the upper box. I considered this somewhat of a vindication of my cabling approach, because running 6 individual wires up there would have been really annoying. We did run two wires from the ethernet jack to the button contacts though.

Although I'm sure it would have been the opposite for an electrical engineer, I found the electronics and build the challenging part and the software comparatively easy. I put together an Arduino sketch to drive the two sets of panels and accept button inputs. Altough the ESP was its own separate microcontroller, I decided the best way to do it was keep all the state and logic on the Arduino, and leave the ESP as basically a dumb data channel.

This means that with the ESP malfunctioning or removed the whole thing would still operate. There's not even a particular necessity for it to be an ESP; they're connected via serial, so anything that can send and receive data could be wired into it. I liked this super modular approach for its prototype-friendliness, and you can get a bit more detail about it in my recent prototype wrapup.

Display box innards

The last part was to build the website. This wasn't too hard either, and as is usually the case with these things I spent most of my time fiddling with formatting and fonts and other silly stuff. The core part was that I wanted the online and offline versions to mirror each other as closely as possible. I used websockets for this, and set it up so everyone shared a 1-second cooldown for button presses. The offline button had the same restriction to make it fair.

The server was just a little Nodejs/Coffeescript thing that dumped data into a redis database, and the client was plain Coffeescript with no extra libraries. Luckily the UI was pretty unchallenging because it was going to be embedded in an iframe on the Artsweek page. Still, it was important to make the live updates and clicking look good.

Finally, with everything written and hooked up, we were ready to go. The website pointed people to the physical button using Google Maps. The physical location pointed people to the link for the online button. There was some last-minute scariness because it turned out the university's WPA2 Enterprise wifi wasn't supported by NodeMCU, so we ended up using a mobile hotspot to get it connected. The display was also a little less visible outdoors than I hoped, but it's pretty tough to beat the Australian sun. Jeeves suggested that recessing the panels more would help, which seems like a good idea.

Ultimately, though, there were no more technical issues for the rest of the event, and people seemed to have a good time playing with it and watching it update. The last hour or so it was moved to the laneway party for the end of Artsweek, and in the leadup to the final 10pm cutoff things got pretty fierce.

Animation of online vs real life click fight Graph of clicks over time

I was secretly hoping for a victory for Team Internet, but Team Real Life were just more dedicated (or maybe Team Internet got distracted by the internet), In the end, irl won the day.

All told, I'd say the project was a success and pretty fun to work on. If you're interested in doing something similar, or just like reading prototype code for fun, you can find everything on GitHub. Finished installation

Stuck in the middle

There are two places you can start when you explain something: with the thing, or with the person learning it. For example, if you're teaching a language: here's the word for apple, here's how you say you want something, now say you want an apple. Here's the word for banana, now say you want a banana – and so on. This is the method used by Michel Thomas, and it has a lot to recommend it. Instead of trying to translate people's existing knowledge into the new language, you just build new knowledge from the ground up.

On the other hand, it can be quite useful to go the other way and build on existing knowledge. Instead of having to start from zero, you can start with something familiar and teach the ways this thing is different. Michel Thomas does this also, in a small way, by teaching cognates. Most latinate languages will share a bunch of -ion words, which can save a lot of time learning vocabulary. This is especially useful if you're furthering some existing education. Rather than having to teach physics from scratch, you can start with existing mathematics knowledge and existing physical intuition.

I think part of what can make programming challenging to teach is that, for the most part, it doesn't obey rules that people are familiar with. Seymour Papert's Logo was a rare example of figuring out an existing intuition that could work in the form of physical movement. However, that's the exception, and I think in most cases programming has to be taught without leaning on many existing intuitions. In theory, this shouldn't be a big deal. Most video games teach people how to play the game in this way and do just fine. Here's crouch. Here's jump. Now jump and crouch. Great!

But the problem is that in disciplines like programming, being good at it looks like the opposite of teaching it well. When you are programming, you have some idea in your head of what you want. That is to say, you have a mental model. Then you use your programming expertise to turn that into a computational model, which you type into the computer. Writing code isn't really the hard bit, it's turning your thoughts into computer thoughts. On the other hand, to teach programming you have to go the other way. At least at first, students don't need to turn their mental model into a computer model, they need to turn the computer's model into their mental model. Rather than figuring out how to translate their existing thoughts into code, they need to learn how to think new, codey, thoughts.

This is a problem that is more apparent the less intuitive something is, which is to say how far apart the model of how it really works is from the model of how people think. Either way you have to bridge those two models to make understanding, but you suffer twice when they're far apart because the teacher has to go so far from their existing way of thinking to be able to teach. All it takes is one innocuous question, "oh, why can't I return an array from a function?" and you're suddenly zooming off into deep space, completely leaving behind the tower of knowledge you carefully built from the bottom up. I'm not convinced you can teach without a hundred diplomatic ways to say "don't ask that yet".

One thing I'm particularly unimpressed with is the power of analogies. I think analogies sound good because they carry the illusion of bridging that model gap. Truthfully, they're just some third model that vaguely overlaps both, and almost always has to make compromises to do so. The rubber sheet analogy is great, but it only really helps people who don't have to actually understand spacetime. If you learn general relativity, you learn the equations, and from the equations you can get to the rubber sheet. But you can't get from the rubber sheet to the equations. An analogy can make something unintuitive feel intuitive, but it can't make it actually intuitive.

For things where real understanding doesn't matter, and you just need some vague notion of how it works, that can be fine. And on rare occasions the thing that appears to be an analogy is actually just a more intuitive model, but to qualify for that it needs to have all the explanatory power of the old model. In many cases, though, I think analogies can do more harm than good. It's comforting to say, hey, don't worry, this new thing is kinda like some old things you recognise. But if it really isn't, all that does is encourage dragging that wrong mental model along with you long after it's become obsolete.

Instead, I think the best option is to give up on finding something that feels right and just learn the mechanics as they are. Who knows, after some time they may come to feel as natural as anything else.