DRMacIver's Notebook
Something isn’t working
Something isn’t working
Loosely based on a stub chapter from the same work as Journaling as a foundational practice.
The core of my approach to a lot of things is embarrassingly simple: If you’re getting outcomes you don’t like, that means something about what you’re doing isn’t working, and you can fix that. A system is perfectly designed to achieve the outcomes it achieves, so if you don’t like the outcomes you have to change the system.
This is in direct contrast to doubling down on the thing you’re doing because if it isn’t working then clearly the solution is to try harder, or to get mad about the fact that it doesn’t work and conclude it must be some failure of yours.
I have a running joke that when I do coaching, a great deal of the value I add is to listen patiently and then say “Yes, that does sound like a problem. Have you tried solving it?”
I very rarely literally say this, but I do often say variants of this. “What have you tried?” is a common one. Often the answer is that they’ve not tried anything. Sometimes they have tried many things, but they haven’t worked.
“They” of course also often means “me”. Sometimes I need someone to say “Have you tried solving the problem?” to me too.
My approach to writing software isn’t that much different. I write software. It’s software, so it has problems. I fix those problems. Sometimes I probably shouldn’t, but ultimately this approach has produced very good results that would otherwise seem impossible, just by fixing the problem in front of me repeatedly and seeing what happens.
Fixing things that aren’t working consists of trying to understand them, based on that understanding trying to change something that you think will help, and learning from what happens then - either its success or its failure.
Ultimately this is a process of debugging, and it feels very much like debugging software, where you systematically narrow down what causes a problem until it’s clear enough to fix.
Software and other crunchy work is very good for teaching this skill, because it provides you with a very tight feedback loop that rewards systematically going through everything. It’s a good type of work for learning how to be better at everything because of how much it rewards diligence.This is interesting contrast to my advice not to just try harder, but I think they’re compatible. The unified advice is that if you’re going to put in more work, don’t put it in by doing more of the thing you’re currently doing, do it on things that you’re not doing because they seem like too much work. A lot of these skills then transfer reasonably well to other environments, as long as you’re prepared to understand how crunchy work and squishy work differ. Nobody likes a software developer who treats everything like a software problem, but part of why that type is so common is that the basic attitude works. Treat things as understandable, and fixable.
For me in particular I use “debugging” as a concept a lot in emotional contexts. e.g. How I fix anxiety triggers is very much a debugging process.
One of the most important things to debug is when you get advice from other people and it doesn’t work for you. It might be that you’re doing it wrong, but it might also be that the advice is not well suited for you.
I’ve said before that the universal disclaimer of self-help books is “This advice has a domain of applicability, and the author is not competent to assess what it is”. i.e. This will help some people, but the author doesn’t actually know who. This applies to all advice, really.
Some (non-exhaustive) ways advice can fail to apply to you:
- There is some ideal middle ground, and this advice is designed for people on the far side of that from you.
- This advice relies on capabilities you lack.
- This advice solves something that’s not your bottleneck.
But from a debugging point of view, this makes such advice actually quite useful.
There’s a book called How to measure anything that I am mostlyI think that there is a target audience for whom it is very good, and I am not that target audience. indifferent to, but that had a fundamental premise that has entirely justified the read for me: A measurement is anything that reduces uncertainty.
In this sense, everything you try while debugging is a measurement. Either it solves the problem, in which case you’ve solved the problem and also learned something, or it doesn’t and you’ve learned something through how it fails. Use that measurement to find out more about the problem. Everything you try is a forking path that tells you something about the system.
So here is my advice: Try more things, take more advice, but notice as you do when something isn’t working, and then fix that.