Last week I made 3 prototypes, but this week I only made 1. This is mostly related to last week's failure, so I expect this is a short-term decrease that will reverse as my time frees up.
I was irritated by a particular Slack bot so I decided to make an irritating slackbot of my own. It turns out making a slackbot is particularly easy with the various Node modules available. I nearly went to the trouble of making it send regular messages, but the cost-to-joke ratio was a bit too high. Still, well worth trying this for the possibility of future Slack shenanigans.
I said last week that I was going to track all my time for the week and see what insight I could get from it. As it turns out, a little bit, but not as much as I hoped. Mostly things were as expected, but there was still enough to be useful.
My biggest chunk of time was, as you would hope, sleep. I clocked 51.5 hours, for an average of 7.5 hours per night. After that was 32 hours of time tracked with no description, followed by 24.6 hours with friends, 23 hours of miscellaneous junk and 23 hours of house-related activities. That big chunk of "no description" time is me forgetting to reset the timer sometimes, but annoyingly means the data isn't quite as complete as I'd like. I suspect that's just a habitual thing that would become easier with time.
The rest roughly lines up with my expectations: I had friends visiting from out of town for the week, so I spent a fair bit of time with them, though I wouldn't have realised how much without the timer. I was also looking for a new housemate, which ate up those 23 house-related hours over the weekend. Sleep was roughly what I thought, but I would have liked a little more.
The miscellaneous time is pretty interesting though. I marked as miscellaneous anything that wasn't useful for anything. I didn't include, for example, things like showering or shopping (they generally went under "maintenance"), or fun stuff ("fun" or "friends", depending), so in theory the miscellaneous category is purely dead time. I'm sure some of it could have been recategorised if I was trying harder, but even so there's basically a part-time job worth of screwing around in there.
To an extent I expected to find a lot of miscellaneous time (it was, in a sense, the point). I want to find out what happens if I start squeezing that time. Does it turn into fun time? Work time? Or maybe there is some inevitable necessity for a certain amount of useless time. Whatever it turns out to be, the answer seems worth finding out.
For that reason and because I want to see what it looks like with more complete data, I think it's worth continuing. I also didn't find it very onerous once I got into the swing of it. The only somewhat annoying thing is tracking when I go to sleep, which I sometimes forget because I'm nearly asleep when it happens. So I'll try to keep this up until the end of April and I'll write an update again after that, where I see if the usefulness equation has changed with more data.
One of the most derided kinds of software, especially among seasoned developers, is software that tries to be smart. For example, a menu that reorders itself based on which items you use the most often. At first blush, this seems pretty clever: items you use the most become easier to access, which saves you time. The problem is that now this smart system is unpredictable. Quick, where do you click to open a new file? The answer depends on all the clicks you've made previously, which makes it very difficult to reason about.
Which means it's often preferable to make software dumb. Dumb software is predictable, like a hammer or a chair. Your chair doesn't decide to remove its armrests because you haven't been using them, and your hammer doesn't try to shift its weight to more effectively deliver force from your wrist. If it did that, and you weren't expecting it, chances are you would misjudge your swing and hit yourself instead. Even though it could theoretically be a better hammer by being smart, a dumb hammer is easier to understand, easier to predict, and much, much easier to make.
But I think this celebration of dumbness easily goes too far and becomes limiting. You start to think that a smart tool is necessarily worse than a dumb tool, and if someone made a magic genie that always did what you wanted it would somehow still be less effective than doing it yourself. Yes, it's easier to make a dumb tool than a smart one, and yes, there are way more ways to get it wrong, but that's a fact about the implementation difficulty, not the outcome. A good smart tool is better than a good dumb tool, but a smart tool is much less likely to be good.
This results in what I think of as dumb valley. Like the uncanny valley, dumb valley is a counterintuitive gap where as your tools get smarter, the immediate effect is that they get worse. Only after a lot of painstaking effort do you begin to climb out of dumb valley into a smart tool that actually works properly. If you're not looking far enough ahead, or don't have the resources to get there, the effective but mistaken conclusion is that dumber is always better.
However, as with the uncanny valley, there is a hill on the other side if you keep going. It is difficult but possible to make smart tools that work properly, and there is every reason to think that, if we build them, they can be better, easier and more powerful than the dumb tools we mostly rely on today. Unfortunately, incrementalism won't get us there. It's going to require a long, brave slog through dumb valley.
I read an article about creating content online the other day, making the point that it's not sustainable and leads to a frustrating compromise: do you create content for free and give up being able to rely on it as your main work, or do you make people pay for it and drastically reduce your audience? One answer that tends to appear in these discussions is micropayments, the idea that each pageview or click or like or something costs a tiny fee.
A lot of time and effort has gone into trying to make general-purpose micropayments work. I don't even mean just the financial backend, though even today Bitcoin is the current frontrunner and still doesn't support them. More importantly, nobody seems to have made the actual product very compelling. Probably the best example we have of effective micropayments is free-to-play games where you pay some (non-micro) amount into a virtual wallet that you then spend (sort of) micro amounts from. Various people have tried to implement that on a wide scale or with micro-er payments, and as far as I can tell it hasn't really taken off anywhere outside of games.
The fundamental issue, it seems to me, is that people just don't think in micro amounts of money. I've heard the micropayment compensation idea dozens of times: each page you view costs a microcent and over the course of the day you've only spent a dollar or two, but that adds up to serious money for the people making the content. I can't see any technological reason it wouldn't work, especially if you followed the wallet formula as set out by game companies. But it just doesn't seem like something people want that much.
Who wants to give someone a fraction of a cent? One of the best things about rewarding a creator is that it feels good, and those miniscule amounts don't feel like anything. What's worse, it completely severs the connection between spending and outcome. It's not even "I paid this person a microcent", it's "my actions set in motion a process that eventually resulted in this person having some of my microcents". Which is doubly unsatisfying: you don't enjoy giving as much, and later on when the total bill is due you probably don't even remember what it was for.
So I'd like to suggest that the real problem isn't making micropayments work, it's making macropayments work. Instead of every piece of content costing a miniscule amount, I'd be happier paying the really good ones a larger amount, say, $5. It would work as follows: you see some content you think is really good. You press the $5 button. The person who made the content gets $5 from you. That's the whole thing.
Right now I think the main thing holding back a macropayments system like that is just that nobody has built it yet. Donate buttons give you too much choice and aren't specific about what you're paying for. Paying people through PayPal or other payment processors takes a lot of clicks. This should be a simple click (or a hold-to-confirm) with an immediate connection between action and result.
You thought it was worth $5, you gave it $5. Simplicity itself!
A year ago, I wrote Keeping a NOTES file, about the benefits of keeping a plain text file for you to dump words into when you're working on a project. I've found it a great way to add a bit more structure and persistance to the otherwise freewheeling thought process that goes with designing something. There's an underlying principle I've since become more familiar with that I think is worth exploring.
I've said before that I think of the brain as an association machine, and inherent in that idea is that it's good at certain kinds of things, but pathologically bad at others. The fuzzy and haphazard way that we walk through ideas associatively is great for creativity, for finding connnections between unrelated things and quickly searching for patterns. It is, on the other hand, complete rubbish at thinking exhaustively or systematically, and constantly gets stuck in self-perpetuating loops and spirals.
But whether by crafty evolution or just pure luck, our communication does not seem to have that problem. When you describe a dream, the messy and incoherent associations fall apart in your head as you try to turn them into words. When you try to explain an idea that you don't really understand, you suddenly realise the gaps in what you know. The process of communicating somehow causes you to linearise these associations, to marshall them into a form that is stable enough to survive transit into someone else's brain. I believe that process is unique – or, at least, I have not found a way to replicate the relative orderliness of communicative thinking other than by communicating.
What that means is that there are lots of tricks besides NOTES files that are worth engaging in as a form of mental linearisation. The symbolic manipulation of mathematics (and programming, for that matter) is a good example: you can think some crazy idea, but when you start trying to put the symbols down you realise it doesn't make any sense, or that it works in a slightly different way to what you expect. I've found literate programming to be particularly good in this regard; it's a kind of hybrid between a NOTES file and a symbolic representation.
One thing that has been surprisingly helpful is to just talk out loud. I'm not sure why it's socially discouraged, because as far as I can tell it is genuinely useful as a thinking tool. I've found both puzzle games and mathematical problems much easier when I describe the problem and my steps out loud as I'm working; that little bit of order is just enough to keep everything organised in my head while I search for the solution.
Of course, in a sense these posts are a way to linearise my thoughts and ideas. Subjectively, I feel like they've brought a lot more clarity to the way I think. Being able to linearise has been helpful in a lot of different situations, up to and including thinking about linearisation itself.
