There's a neat concept in physiology called recruitment, usually used specifically to talk about muscle fibres: a muscle wants to contract, and the stronger a contraction the more fibres are recruited, starting with smaller, more efficient ones and eventually pulling in everything available. Similarly, on a large scale you can talk about muscle recruitment, where muscles are used to implement some movement strategy, starting with the most efficient and moving to less efficient ones as required.
I think this is a neat metaphor for general use: you have a macro-level goal and you recruit micro-level resources to achieve it. At first, you're going to recruit the best and most efficient resources, but if those resources aren't enough then you recruit less and less efficient ones to make up the numbers. It dovetails nicely with something I wrote before about habits as raw material: habits are something you can recruit to achieve your goals. If you have lots of resources available, you can recruit the best of them to achieve what you want.
But what if you don't have the best resources available? I wrote recently that my prototypes have been acting like stages of a larger project. I had even noticed right at the start that my prototypes seemed to want to get large and try to turn into mini-projects. Why is this? I believe one answer is that I didn't create an outlet for small projects, which is something that I clearly enjoy doing. In other words, my macro-level desire to do bigger projects was recruiting my prototype resources. That, in turn, was making it more difficult to do actual prototype-sized prototypes.
The physiological equivalent is called compensation; when some injured, absent or weak muscle is unable to perform the movement you want, your brain will recruit secondary muscles to get the job done. This leads to two problems: the secondary muscles are overused (and sometimes get injured themselves), and the primary muscle becomes underused and weak. It works fine in the short-term, but often leads to chronic issues in the long-term.
In my case, it would seem that I am compensating for the lack of a developed habit for creating small projects by recruiting my prototypes to do it. The obvious answer is to create that project habit. I originally avoided this because I wanted to focus on the prototypes without getting distracted. I think now that, rather than being a distraction, projects may actually contrast well with prototypes. Having a specific place for mini-projects will remove the temptation to abuse my prototype resource for something it wasn't designed to do.
In general, it seems like a useful activity to think about whether the structures, systems and habits in your life are actually the right ones for the goals you have. If not, you may end up recruiting them for your needs anyway, just because the right resources were unavailable or underdeveloped. Compensating in this way still works, but much less efficiently, and can end up causing other problems.
A year ago, I wrote Fail scale, about the value of considering not just success or failure, but how much. Something you just barely succeed at is worth thinking about and learning from every bit as much as a failure. I described near-misses as a "valuable signal", and I'd like to take a step back and examine the idea of signals, and how both failures and near-misses are examples of them.
An important question is: why fail at all? I mean, why bother having a notion of failure? Failure is generally considered a character flaw (outside of a few specific circles where it's celebrated), usually doesn't feel nice, and can be embarrassing. I previously wrote that frames of reference are valuable even without judgement or goals. Can't we just try our best to improve relative to those frames of reference without any thresholds of success or failure?
One answer is that thresholds match up with people's expectations better, which is true but not very interesting. I think that even in the absence of external pressure, failure is useful because it directs attention to where it's needed. Your life has hundreds of different aspects, and while it might be possible to measure them, it's not really feasible to pay attention to all of them at once. Whatever you're not thinking about might slip when you're not paying attention to it, and you want some signal when that's gone too far.
For example, I'm not currently paying a lot of attention to my diet, but if my weight increased beyond a certain level that would be a signal that I should start eating better and pay more attention. I haven't got a particular number in mind, but I do have a general idea of what would constitute an issue. I could obviously prevent that from happening in the first place by paying more attention now, but that would necessarily take attention from somewhere else, and maybe it won't be a problem at all. This signal lets me focus more judiciously.
A failure is just a particularly strong signal telling you that your plan isn't working. Unlike excessive weight, which is a signal about your eating system, a failure is a signal about your planning system. This is why I said that ignoring or hiding failures is terrible, because a failure to deal with your failures can have much wider-ranging consequences than any individual failure would. Any time you've set up a threshold for success or failure, it was to focus your attention on this particular outcome. Minimising that failure does the opposite.
With that in mind, we can now return to why near-misses are a useful signal. As in the weight example, you probably want to catch a problem before its consequences get too bad. So ideally you wouldn't get a signal to pay attention after a failure has occured, but early enough that you have time to do something about it. Essentially, a near-miss is a signal that a failure is probably coming. This means it's especially useful for situations where the failure's consequences would be particularly negative. You can get the signaling benefits of failure without having to pay its price.
One last thought on this, which is that thinking of failure as a signal that focuses your attention also means accepting that too much failure is not very useful. Your attention can't be everywhere at once, and failing over and over doesn't help you learn. In fact, thanks to the what the hell effect, it's more likely to make you give up. Conversely, too little failure is also not very useful because you're wasting a valuable signal.
Every now and then I think about the weirdness of big companies. The number of developers at Google is likely somewhere between 20,000 and 30,000. That is a mindbogglingly large number. To put it another way, 5 ex-Google developers would make a pretty decent software startup, and you could make 4,000 such startups. Whatever Google's doing, it's hard to believe that it has the same impact as 4,000 startups. On the other hand, maybe there's certain problems you can only approach with tens of thousands of engineers.
It strikes me that part of the problem with big companies is that they don't have the same volatility as small companies. Startups appear and disappear all the time, which gives them a certain flexibility, and a certain hunger for success that slows down as they gets larger. That may be a good thing when you have older products to support; the last thing you want is volatility when you're paying for some business-critical enterprise software. However, for new projects or fast-moving sectors, you need innovation and efficiency, and big companies rapidly lose that young and scrappy edge.
Many companies try building internal innovation departments, to a certain degree of success. But I think what's really needed is a way to build some degree of attrition into the company. Cruft slowly accumulates over years of operation, in the form of bad practices, bad projects, and bad people. Often the reason these things stick around isn't because anyone wants to keep them, it's because nobody wants to get rid of them badly enough. An attritional company would be one where the default is that all these things slowly disappear unless they repeatedly justify themselves.
A radical way to implement this would be what I'm calling a cicada company: a company that sheds its skin periodically, say, once a year. So 2012-Google works on all the projects launched in 2012. At the end of the year, you launch 2013-Google. 2013-Google operates new projects or projects specifically carried forward from a previous year. The only way that happens is by mutual agreement, and the different years don't necessarily share management. In fact, rapidly promoting (and testing) management would be another advantage of the cicada company.
2012-Google wouldn't disappear entirely. Instead, it would continue to run whatever projects it didn't want to give up, or that 2013-Google didn't want. Over time, it would get older and stodgier, and slowly make the transition from hot new 2012-Google to reliable, legacy 2012-Google. Any projects that stayed with that company would also slow down. Eventually, 2012-Google would wind down entirely, or maybe just bumble along indefinitely, as is often the way with old enterprise companies. Meanwhile, 2013-Google is where all the projects and people looking for fast-paced work go.
If this worked, it would mean a constantly-evolving CURRENTYEAR-Google, always working on the cutting edge and honed by endless attrition down to just the best and most innovative projects. Anything else gets left behind to stabilise and, eventually, stagnate.
What a piece of work is a man! How noble in reason! How infinite in faculty! In form and moving how express and admirable! In action how like an Angel! In apprehension how like a god! The beauty of the world! The paragon of animals!
It is easy sometimes to get pretty impressed with ourselves. Look at our amazing society! Look at all the things we've done! We dragged ourselves out of the dirt to reach up to the stars! That is, unquestionably, impressive, but it would be an error to say that because humanity has achieved so much, humans must be beings of supreme judgement and reason. That's no more true than saying that because we can swim, we are marine animals. We achieved these things despite our biology, not because of it.
The entire space of productivity, self-improvement, cognitive science and so on is built on understanding and managing the ways that our actual brains depart from being noble in reason and infinite in faculty. Brains are not logical, not rational, and in fact I would describe them as nothing more than the simplest thing that evolved to be capable of higher-level understanding. Our genetic legacy is not a gift of god-like apprehension, but something more like the first rough draft of intelligence. All of our attempts to improve ourselves are, at root, ways to work around the limits of our minimum viable brains.
Which isn't to deny that humanity is actually pretty great. In fact, all the greater for having done so much with so little. We built towns and cities, authored innumerable works of art, walked on the moon, connected the world, fought and continue to fight valiantly against death and disease. It is likely that someday we will spread across planets and even stars, look back on the tiny people we were in this tiny place, and marvel at it. All of that, all of this, from the same brains that evolved to throw poo at rivals.
So it seems to me that a certain level of humility about our faculties is justified, and with that understanding comes two important goals: Firstly, to pave over the quirks of our evolutionary history and make the best we can of our limitations, correcting or compensating for our flaws as necessary. Secondly, to work towards a future where these workarounds are no longer necessary, where we can remake ourselves in that aspirational self-image of noble reason and infinite faculty, where we can think clearly without the fog of biases and distortions, and where we finally live up to that divine ideal.
Last week I made 1 prototype, and this week I made 1 again. I've noticed that my prototypes for the last few weeks have really just been stages of work on one larger project. This isn't a bad thing per se, but I feel like it's not the right place for them to end up. I suspect that part of what has made working on these smaller prototypes difficult is tendency for them to fulfill a need for larger projects. More on that in a later post.
This was the last bit of code necessary to make my record-and-playback idea work. I renamed it from пере to pere (the romanised version) because the novelty of using Cyrillic characters fairly quickly stopped being worth the difficulty of typing them. I added an extra record/playback API that returns or accepts an array of edits instead of emitting them one by one. I also added timestamps and cleaned up the edit data a little so it uses less space. All told it was enough to get the red-green-refactor demo working, which I think turned out pretty well.
