Well, another week, another failure. But it's a different failure and, as so often in programming, sometimes a different failure is the best kind of progress you're going to get.
This was a kind of compound failure where my goal for releasing the commitment platform I committed to last week conflicted with my new rules for when I count a failure at writing. I'm happy enough with the sacrifice I made (the commitment platform is coming as my next post), but I'm not sure it was strictly necessary to make that sacrifice at all.
In reality, the flexibility I built into my posting commitment should have helped me in this situation, but I was already one behind from the previous day. That says near miss to me: being a post behind became a fairly common state rather than an emergency. I'm beginning to think that this flexibility thing might be more trouble than it's worth.
A separate but related near miss is that, despite my good intentions with planning work on the commitment platform, I still did the bulk of it at the last minute. I did some design and planning earlier in the week that was actually very helpful, but not enough to significantly spread my workload out through the week. I got it done, but I didn't get it done comfortably. In fact, I would say I barely scraped over the line.
I think the issue was that I put effort into estimating time, but I didn't make much effort to schedule that time earlier in the week. I'm going to try that with the next big chunk of work I dedicate myself to, but that probably won't be until the following week so I can have some time to recharge and polish the stuff I did this week.
I wrote before about "it's the opposite to the one I expect" as being a particularly useless way to remember something. The problem is that as soon as you internalise it, it's not true anymore; if you always turn the tap the wrong way, and you remember "I should turn it the opposite way than I normally do", that system becomes useless as soon as your idea of normal changes which, if things are working, should be really soon.
I've been thinking that there's a more general class of problems along those lines, which are non-idempotent habits. Idempotence is something you often talk about in software to mean something that you can do multiple times with the same effect as if you did it once. So adding 1 isn't idempotent, but changing your name to Steve is. You can change your name to Steve as many times as you like and you're still Steve, but if you add 1 twice you've actually added 2. Idempotence is often considered a sign of a well-designed system.
The reason I think this is particularly important for habits and other mental systems is that, unlike a computer, we tend to operate on patterns and associations. So a non-idempotent habit tends to stick around even when it's not useful anymore. I started using 24-hour time and one nifty shortcut I found was that in the afternoon I could just read the 24-hour time as the 12 hour time, by ignoring the first digit and subtracting 2. 1900 is 7pm, 1400 is 2pm, that kind of thing. The only problem is that I kept catching myself looking at 1900 and thinking "that's 5pm". I got so used to subtracting 2 that I was doing it twice!
That's a pretty innocuous example of how non-idempotent habits can get you in trouble, but there are others like "I'll try to be more assertive" that have similar issues. More assertive than what? Than you are now? That will change as you change to feel more comfortable with your assertivenes. Or if you tend to be really behind on things and you build habits to deal with that, those habits stop being useful as soon as they start working properly because you're not behind any more. The high water mark I wrote about before is another example.
Something all of these have in common is a certain degree of self-reference: the habit changes based on its own output. I think a better answer is to find fixed points of reference to anchor habits to. Instead of being useful at first and counterproductive later, an idempotent habit will stay relevant over time. That means less habits but stronger ones, because they have more time to build.
There's a technique I've found useful when dealing with difficult requests. Often this comes up in a business setting, but not exclusively. A lot of business types tend to deal in abstractions of value, which is usually fine as long as you can convert everything into the right units. However, sometimes there are essential mechanical reasons why something is impossible, and you have to deal with that in the concrete, rather than the abstract.
Usually you don't get presented with an impossible situation all at once, instead you get one requirement first and another conflicting requirement later. Then the problem is you're in a difficult situation because you have to say no to this new requirement, or you say yes and then can't deliver it. What's happened is you have inadvertently been shifted into a decision-making role by proxy. This smaller decision (technical requirement A vs technical requirement B) is really reflective of a higher-level decision (business need X vs business need Y).
The problem is that while it's obvious from your perspective that A and B conflict, it's not obvious from a business perspective that X and Y do. And turning around and saying "sorry you can't have B (and therefore Y)" just makes you sound obstructionist. Instead, I recommend hoisting that decision up into the higher level, and pushing it back on whoever asked for it. That way, instead of being responsible for saying yes or no, your job is just to explain the tradeoffs and leave that responsibility to the people making the decision.
I find decision hoisting can be pretty useful in everyday life. In some cases, your answer to a request might just be "no", but it's more often "it depends on the circumstances". I once had a friend ask me to go to a party that I didn't really feel like going to. I put the decision back on him by saying I'd only go if he drove me. He put the decision back on me by saying he'd only drive me if I paid for the petrol. I agreed with that and we both got what we wanted, though the decision had to go through a few domains to get there.
The main benefit of decision hoisting isn't that it stops you from being responsible for decisions, but that it moves decisions into the domain they should be in. Business decisions shouldn't be made at a technical level. Instead, the technical realities inform the business decision. Doing it that way means you can make better decisions, because you don't eliminate legitimate options by saying "no" prematurely.
I've previously mentioned how convenient it is that paradoxes don't affect us the same way they do a more formal system. Gödel, in his day, managed to prove that all complex formal systems have unanswerable paradoxes built in. That threw the mathematicians of his time for a loop, but nobody seems too concerned about paradoxes in the brain. This statement is false. See? You're fine.
But you could easily make the argument that those kind of paradoxes don't really affect our thinking. The same way that I can type the letters "this sentence is false" into a computer without causing any problems, we can think about an idea without believing in it. But there are contradictions that do appear in our beliefs and how we make decisions. I'm a particular fan of the trolley problem series of dilemmas, which often reveal contradictory ideas you've held for a long time without realising.
However, it's rare to see a trolley problem seriously affect someone. In most cases I think people do a good job of resolving contradictions, usually by not believing one of the beliefs anymore. In fact, it seems like most inconsistencies only last until you realise there's an inconsistency. But, to me, it's not a paradox if you can just solve it; with a paradox there's meant to be no way out. I think what would qualify as a mental paradox is a situation where you believe two contradictory things and you're not able to stop believing in either of them.
When you believe in something in a way that you can't stop believing, that would look like reality. So we're looking for a situation where the reality is impossible. Where you have to take option A, but you can't, so you have to take option B, but you can't. This is the sort of situation where you're completely, utterly trapped, and there are no options. I think what you feel in that situation is simple: despair.
In which case, perhaps despair is nothing more than what a paradox feels like. On the one hand, that means paradoxes can be very harmful. But on the other hand, perhaps knowing that you're experiencing a paradox could provide some comfort, as well as a healthy dose of encouragement to check your assumptions. Actual paradoxes are, after all, quite rare – Gödel notwithstanding.
Something a little lighthearted for today. I made a mashup of Drake's Hotline Bling and the Shop Theme from Ocarina of Time.
Most of the effort here was just in realising that the two songs were so similar. In the end I actually didn't need to do very much to line them up: the songs are structurally identical, the bpms are very similar, and the musical styles mesh nicely. I couldn't find a decent isolated vocal track so I had to make do with just EQing down most of the Drake track.
Originally I uploaded this to YouTube, but it was immediately muted by Content ID, which as I understand it is a system that music companies use to prevent their work from inadvertently giving rise to creativity or culture outside of their control. The world will be so much brighter when they're gone.