Those who can't do

There's a particularly troublesome kind of writing that I and many others engage in, which is speculatively writing about some new goal, plan or system we're going to implement. This makes a certain kind of sense, because when you're used to writing about your ideas and you have a great new idea about how to do things better, of course you're excited to write about it. So you make a post like "I'm going to implement GTD now! GTD is going to be amazing and wonderful!" But if you haven't done it yet, how do you know?

When you read something like this, you're only getting one half of the picture. It's not really fair to write speculatively about a system; it distorts reality by making it appear that this system is more useful than it is. You get all of the "everything's going to be amazing" hype, but none of the tragic reality of "actually, it didn't work for me and I ended up stopping it". In its most extreme form, this can lead to very popular systems that don't actually work, like the infamous Uberman sleep schedule.

That's a problem for the audience, but I think there's also a significant problem for the author. Gollwitzer wrote that announcing your intentions in public can actually make you less likely to do them because merely announcing your plans feels good in the same way as actually implementing them successfully. Since the former is (much) easier than the latter, that means you lose the motivation to actually follow through. So not only does speculatively writing about a new system distort other people's perception of that system's usefulness, it also harms your own ability to implement it.

I think the solution to both problems is the same: accountability. It's not sufficient to merely say "I'm going to do this new thing"; to be truthful and maintain your motivation you need a specific plan to implement the thing with accountable results. I think a decent template for this is my recent time-tracking idea, where I committed to follow up in a week and a month with results of how useful it was.

Time-tracking aside, I'm often as guilty of this as anyone else, so I'd like to make an additional commitment: I won't write things that extoll the virtues of some particular system (mine or someone else's) without making an accountable plan to actually use that system and report back on its results. If I'm already using that system at the time, I'll just write what I've already observed, but for something speculative I have an obligation — to the truth and to myself — to pair the plan with the results.

Failure

Well, this is failure #3 in relation to falling behind in March. That's counting in terms of distinct failures in decisionmaking. If you're counting in terms of number of posts that haven't been on time since then it's more like failure #39. That's a big number!

So what happened? I think the simplest answer is that I was overoptimistic about catching up. At the time I recognised that it was going to be difficult, but I thought it would be an interesting challenge. That was true, but as it turns out the challenge was perhaps excessive. I was really endorsing a sort of trying hard mechanism where I would just muscle through the problem, but I didn't have a plausible mechanism for actually achieving that.

Ultimately, the outcome was that I would nearly catch up, but the effort of doing so was large and easily upset by minor problems such as getting stuck on some prototype. Even if I managed to catch up, that would often be exhausting enough that I would immediately fall behind the next day. Worst of all, I think it normalised the situation of being behind, to the point where it lost its power as a signal that something's wrong.

All of which is to say that I think there's a solution here, and it looks like the following: just be up to date. Clearly, not being up to date has significant costs and I don't think it makes sense to pay them anymore. However, I won't make the mistake of not having a plausible mechanism again. Today, I'm going to write as best I can to catch up (within a reasonable timebox so I don't get too exhausted by it) and whatever posts I can't complete I will replace with sketches of birds. But, one way or another, this is the last day that I will be behind.

I'm considering this my general-case solution for the problem of being significantly behind. Clearly my existing system of failure posts tends to work well for small slip-ups, but not for large ones. That needs a new system, and the new system is bird sketches.

Prototype wrapup #18

Last week I made 1 prototype, and this week I made 1 again. I wrote recently that I feel like my prototypes were being abused to fulfill a desire to work on small projects. I attempted to fix this by working on a prototype that would help me keep my prototypes small. In a fairly predictable twist of massive irony, that prototype turned out to be too large and ended up as basicaly a small project. I think I need to be more careful about avoiding prototypes with producty goals.

Sunday

I started working on a little countdown timer project in Elm. I'm still hopeful Elm can be a really powerful way to write functional web applications, but so far it's mostly been a pain in the butt. This time I ran into a bunch of issues to do with updating changing quantities (like time or URL fragment) and getting their initial value. You seem to have to do these two parts separately which seems really inelegant, and it turns out getting the current time is basically a nightmare. I got enough working that I could count down to a time specified in the URL fragment, but that's mostly in spite of Elm, not because of it. I'm hopeful that with a bit more practice it will get easier, but I also have a gnawing suspicion that web-based functional programming may just be more trouble than it's worth.

Concentrate

I don't know exactly when it happened, but at some point all the supermarkets stopped selling regular dishwashing liquid and started selling dishwashing liquid concentrate. It's more efficient, you see, because you can use less of it to get the same result. The only problem is, I don't think anyone actually uses less of the concentrate than they did of the original liquid. So really you're just buying more and using more for no reason, not to mention I'm sure it costs the companies making it much less to ship the concentrate. Pretty clever marketing!

Though this issue might seem limited to my sink, it has wider-reaching consequences. The modern information era is all about concentrating things because there's no damn time to take it all in. Instead of reading a whole book (of thousands on your to-read list), you can just find a 15-minute summary. Instead of learning all the details of an emerging situation, you can get a concentrated version on a news site, and a concentrated version of that on Twitter, Facebook, or the top Reddit comment.

That's not to say these concentrates are necessarily bad things. Frankly, our brains are struggling to keep up. We're drowning in an unstoppable torrent of information and something's gotta give. Either we know about less things or we know less about them. If you can get a 15-minute understanding of an important idea, isn't that better than no idea at all? I'd say yes, with one super-important caveat: you can't consume concentrates the same way you would the original.

When you're reading a long non-fiction book, it's pretty reasonable to do so at a level of low attention. After all, the author usually takes a while to make their point, and will often make the point a few different ways to make sure you got it. There's redundancy in there that lets you be a lazy reader. Not so with a 15-minute summary of a 15-hour book. If you miss a single sentence, you're missing a whole chapter. If you don't understand some point, you're not getting a second chance. A concentrated book has to be read meticulously, more like poetry than prose.

The same issue is very common in logical languages, like those used in mathematics or programming. In their own way, they are concentrates. Each keyword in a computer program or symbol in a mathematical proof contains very densely packed information. In fact, one of the hallmarks of both fields is that if the information is not packed densely enough, usually someone will come along and invent newer, denser terms for everyone to use. Reading these languages is a unique skill; it requires learning not just the rules of the language, but the discipline to slowly unpack the meaning in each statement.

The most intense concentrates of all are found in science. Scientists might spend years designing a study, getting approval, finding funding, running experiments, analysing results, and carefully documenting their conclusions. All of that can end up distilled down to a single money quote like "differences between the observed and expected deaths are statistically significant (X² = 8.5, n = 3, P = 0.04)" – that example from the famous British Doctors Study on mortality and smoking. That's basically the whole paper right there. "Statistically significant" and some numbers is all you really need to know.

But how does that experience feel? Does looking at a number saying that smoking kills, or a single-sentence answer to a question like "Do vaccines cause autism?" convince you the same way as a heartfelt anecdote from a family member or TV celebrity? Can the distilled essence of thousands of hours of research outweigh a made-up opinion, even if the former gets 3 words and the latter gets 3000? Can we learn to read in those few words all the significance that was left off the page?

If we hope to use concentrated truth to inform us, we're going to have to.

Pere

I said recently that I thought my prototypes and small projects could both benefit from having clear outlets with clear separation between them. That means making more effort to put out small projects. I'm starting with a release of pere, the library I wrote for my post about red-green-refactor writing. It can watch an arbitrary series of changes to an HTML document, store them, and replay them later.

This project was built out of a series of prototype steps: calculating the text diff, watching changes in the document structure, and actually implementing record and playback. The extra work on top for this release was largely just documentation. It was kind of neat having the prototypes support the project, even if in this case I think it had a negative effect on prototyping. It could be a cool model for future projects to have prototype work contribute towards project work. The trick would be keeping the prototype part fully detached from reality and doing all the polish and fleshing out in the project part.

I'm pretty happy with pere. I couldn't find anything else that did the thing that I wanted, so it feels like a pretty good contribution to the problem space. If you want to play around with it you can find the code on Github and a demo .