This was the final version of the Lightblue Bean receiver code that triggered the servo and motor. I ended up having to do some extra tricky stuff because real life is harder than theory. Firstly, the servo and motor were powered by a USB battery pack which kept turning itself off. I considered this nifty solution but ultimately I just cheated and made the servo wiggle itself every 15 seconds. Secondly, the bluetooth interrupt gets triggered slightly before the data on the serial interface is ready, so I needed to wait a little while to synchronise the two.
Finally, I rewrote the main router/controller program to make it work more reliably and have a web interface. The beans were tricky to keep connected, not least of which because of a bug that made the bluetooth stop scanning for new beans once it had found one. I just added lots more rescan calls and that fixed it. Adding a web interface made it easy to check if everything was connected properly and debug problems with individual beans, since it displayed all their serial messages.
I've been thinking about a puzzle game idea that could be pretty fun. Basically, you're given an input signal and you have to turn it into the right output signal by adding components. So you get a square wave in, you want an inverted square wave out, and you need to put a NOT gate in the middle. As the levels get more sophisticated, you need more and more components.
But what could be really interesting about it is that, unlike a lot of puzzle games where you try a solution and then it works or it doesn't, this would have live feedback. So you see your square wave input moving in real time, and as soon as you connect the NOT gate to it you see the inverted square wave on the other side. The expected output is live too, so you don't have to click a "try my solution" button. As soon as your solution works you'll know.
In a sense, the "input" and "output" ideas are arbitrary too, because they really just represent fixed nodes. You could say you need to make the input match the output, but it would be equivalent to say the output has to match the input. In fact, you could really have any number of fixed nodes that you have to connect in a way that works.
At first the levels could be simple things to introduce basic digital logic concepts, but before long you could do more sophisticated stuff, build complex gates out of simple gates, make half-adders, full adders, flip-flops, that kind of thing. You could even break out of digital logic land entirely and go analogue, have resistors and capacitors and so on, though that would really be a different (but similar) game where you have to think about current as well as voltage.
I think there's something very interesting in the space of these games that are educational in the sense that they are based on rules from real life, but not specifically designed to teach. Rather, they assume the topic is inherently interesting, and just let that interestingness express itself through the rules of the game.
I've been thinking about what changes I need to make for my future posting plans, and along the way I started thinking about a structure for these kinds of problems in general. A lot of things I want to do involve managing two distinct processes: an internal creative one and an external expressive one. These processes work very differently, but to make the whole thing work you need some way to synchronise them. My idea for doing this is called process pipelines.
A process pipeline is a system for a given project (say, writing) where each result goes through a number of stages (say, idea -> outline -> draft -> final). Separately, you have some kind of release schedule that you want to meet. That might be the two-week cycle common in software, a daily habit, or even monthly major releases. Each bit of work in the pipeline will take a slot in your release schedule. That can either be attached to the work (ie this project is for the November release), or to the slot (ie this November I'll release whichever project is the furthest along).
This provides an orderly way of tracking the internal process on a project, the external process of releasing it, and the connection between them. It's particularly relevant for creative work because of how unruly that work can be. You don't know when an idea's going to come, so you need to be ready to store those ideas in a place where they can eventually be developed. But you may also get partway through some work and get stuck, and often the best thing to do is just leave that work where it is and focus on something else for a while. As long as you're moving something through the pipeline, that's still a result.
Crucial to this is using the data that the pipelines give you. How many things do you have in the idea stage? How long does it take you to get from draft to final on average? Which stages have lots of items and which have very few? Which stage is the most difficult, and can you make it less difficult or break it into more stages? Are some stages easier to work on at certain times, in certain places, or in a certain mood? Is the total time to finish the next piece of work less than the time until the next slot? If not, you have a problem...
The other nice thing is that it makes matching work to releases more obvious and explicit. You can allocate work to slots, which becomes easier as the work gets closer to final stage. The slots with no work allocated should be obvious, making it easy to figure out what needs more development. You can build up a buffer of work in the final stage so that releasing is always easy, but also you can explicitly decide what to do with release slots that don't have any final-stage work ready. Either you can release some earlier-stage work or just miss the slot, depending on your preferences.
A while back I wrote about consistency, and the difficult question of how to balance the structure necessary for creation and the structurelessness necessary for creativity. I'm hopeful that this might be one answer: don't try to solve both in the same way. Rather, have one system that captures the unpredictable output of the creative process and link it to another that describes the predictable output necessary to get that creativity out into the world.
I have a lot of difficulty telling the difference between two similar situations: overwork and inertia. When I'm overworked I just feel like doing nothing. When I haven't been doing anything for a while, I just feel like doing nothing. As far as I can tell, the two feelings are identical – but they have opposite remedies! If I push myself to keep working when I need to not be working, that's burnout territory, whereas if I don't push myself out of inertia then, by induction, I never get anything done.
I've previously written about this kind of duality, both in Two-phase burnout and in Starting inertia. In both cases you need different strategies for the different stages. Unfortunately, although recognising that there are distinct stages is useful, it doesn't help that much unless you can tell which stage you're in.
So I've started to think about what kind of instrument would tell the difference. For the most basic kind of overwork you can measure it in terms of hours, so if you feel like not working and you haven't done any work in a while, it's probably not because you're overworked. On the other hand, if you're racking up hours and constantly off your feet, you can safely rule out inertia.
However, that basic analysis has some problems. Firstly, depending on how difficult the work is, how unpleasant it is, or how much initiative it requires, the number of hours you can sustainably manage is going to be very different. Secondly, the decisions and the consequences can happen at different times, so maybe you haven't done any work this week, but that could be because you were previously overworked and still haven't recovered.
You want a burnometer: something that, rather than measuring some likely cause of burnout, detects its effects. After all, if being burned out causes such a severe impact on your work, it should be pretty easy to measure. I haven't figured out exactly what measurement is best yet, but I'm thinking either some standard inhibition test like the Stroop test, or an everyday simple but motivationally taxing task to act as the canary in the coal mine. After all, if you can't bring yourself to wash the dishes or clear your desk, maybe that's good evidence that you need a break.
Regardless, what I think is most important about this is having an objective test. One of the biggest difficulties with motivation is that it suffers from the impaired awareness problem: you can be too burned out to recognise that you're burned out, and you can be so stuck in inertia that you don't even think about getting out. Having an objective burnometer to rely on would be a big improvement. I'll report back if I find one that works.
A year ago, I wrote Against identity, where I argued that identity is an inelegant hack. After all, why call yourself a widget-maker when you can just make widgets? Why call yourself a Jazz-liker rather than just liking Jazz? In making sure we have the right labels for things we sometimes forget that the labels can never mean more than the things they label. You can call a spoon a fork if you want, but you still can't eat soup with it.
While I still believe that, I've come to soften my position a little. Identity is not useful for you, or for people close to you, but what about everyone else? You label a drawer because it takes less time to look at the label than look in the drawer. Obviously, the drawer could be mislabeled, or it could have more things than fit on the label, but that's still going to save a lot of time compared with having to look through every drawer for every thing.
So when you introduce yourself to someone new, what do you do? It's all very well to say "I am a complex person with lots of different interests", but what information does that actually give? It's like those people who like every kind of music. Good for you, but it's going to be tough to go anywhere with that. Sometimes you gotta be prepared to reduce, to find a shallow representation of yourself that someone can understand at a glance, something proportional to their mild level of initial interest, something they can sink some hooks into and build associations from. Leave the complex inner world for later.
But it's very important to hear what I'm not saying. These labels are for other people, they're not for you. You have the time and the energy to understand yourself without labels, so best not to get too worked up about "I'm a this" and "I'm a that", especially not in place of the hard work of actually doing things. The causal arrow only goes one way: doing something → being someone, not the other way round.
In fact, it might not be a terrible idea to get this kind of external identity in an external way: ask people close to you who they think you are. If it doesn't match up with who you want people to think you are, then I guess you've got work to do.
