I had a neat idea today for a way to teach the mechanics of programming. It's in the spirit of Zed Shaw's "learn the hard way" philosophy which says, in short, an often neglected part of teaching programming is teaching the mechanics of writing code, rather than just the theory of programming. In practice, that tends to look like a lot of typing.
So I think it'd be great to make something that focuses on a common mechanical technique – say, abstracting two identical statements into a function, or wrapping something in a loop, or renaming a variable – and could generate an infinite number of variations of those problems, and check the solutions for correctness. A standard session with this tool would look like running through fifty demo exercises in quick succession.
Although this might seem like it would only be useful for new programmers, I think there would be some benefit even for experienced programmers. Much the same as even advanced musicians still play scales, being able to do the basic mechanical techniques more quickly and mindlessly could help save a lot of time and energy in total.
It's easy to think of constraints as limiting; by definition, they place limitations on what you can do. Especially if you're working creatively, it seems obvious that the more freedom and flexibility you have, the more room you have to be creative. However, I've found the opposite to be the case, and in fact reducing my available options and the number of ways I can be creative has been a very useful creativity-promoting technique.
I think the reason for this is that your brain works very effectively as an optimisation engine. However, each additional dimension, each degree of freedom it has to optimise severely increases the difficulty of that optimisation. It's the reason you don't learn piano by starting with improvisation: the optimisation-space is too large. If you can cut it down to a manageable size, you get much better creative output.
I've found this helpful not just in terms of reducing the complexity of the creative problem, but in reducing unrelated problems. For example, I think if you want to be creative in your work, you should be uncreative in how you work. Trying to compose a sonata on a honkey-tonk piano that you only play at your mate Steve's house on weekends is adding unnecessary difficulty, even if it seems more artsy and creative. A more stable environment makes it easier to be creative within that environment.
So constraints, in the sense of things that constrain the problem space, are more than just a creative trick. In fact, I consider them an essential tool for solving problems.
When setting goals it seems like the temptation is to go long-term and general ("what do I want my life to be?" "where will I be in 10 years time?" "what do I want to do before I die?"), or short-term and specific ("I want to quit smoking", "I want to get this project finished", "I want to get in shape"). But I think there are issues with both those approaches.
The abstract goals suffer because whatever you decide in the long term is hard to translate into consequences now. And your specific goals suffer because often the short-term turns out to be longer than you expect. In effect, I think both "do immediately", and "do eventually" are off the mark. Instead, I prefer to think "what would I like to be in the middle of doing?"
The reason is that being in the middle is actually where you will be the vast majority of the time. You'll only be in a position to know if you've satisfied a 10-year goal after 10 years, and in the mean time there's a lot of unknowns. Conversely, most of the immediate goals are actually part of a pattern of actions over a longer time. So instead of "getting in shape", it may be more useful to think "if I want to be the kind of person who is in shape, what would I need to be in the middle of doing often."
I think these kinds of questions encourage thinking about your life as trying to converge on a continuously optimal situation, rather than a series of discrete "win" points which, although they feel good, are fleeting and lose their flavour quite quickly.
I think right now battery technology, or, I guess, energy storage in general, is the most significant arm of technological development. So many other important technologies depend on batteries, and would benefit so much from significant breakthroughs in battery technology.
Mostly, I think of batteries along two dimensions: battery life, and battery size. Obviously those are kind of related, in the sense that you can make a longer life battery if you can figure out how to make batteries smaller and just use more of them. Unfortunately, progress in those areas seems to have stagnated over the past few years.
But, having started using a phone with the new Quick Charge system, I've begun to realise that charging time actually makes up a fairly significant third dimension. If you can charge a device quickly enough that recharging stops being inconvenient, then battery life stops mattering as much. At an extreme, you can imagine a battery that charges instantly, at which point you could just touch your phone to a charging point for a second if you ever notice it getting low.
It seems like this is one of those situations like CPU development where physical limitations are stopping us from making much direct progress, and future gains have to come from making clever end-runs around the problem. Those end-runs come from figuring out some other dimension like recharge speed that can still be optimised, even if it isn't the thing you set out to improve.
An interesting way to think about decisions and how to evaluate them is to consider input and output separately. Inputs are all the decisions and things that you control. Outputs are the consequences, or the goals that you measure but don't necessarily control directly. It seems like in certain situations you can come to very different conclusions depending on whether you're measuring input or output.
For example, imagine a startup you're working on doesn't get any traction, runs out of money, and fails. Okay, so you must have done something wrong if you failed. But that scenario only describes the output half of the situation. Perhaps the startup failed because you made mistakes, or perhaps you did the right things but the startup concept itself was just bad. Or, and few startup people seem willing to admit this, maybe you just got unlucky. I think in this case measuring your own actions – the input – is more useful.
On the other hand, imagine you have a friend who is going to drive home drunk, and you want to stop them. Maybe you talk, ask, plead, convince, argue, and so on, but nothing works. "Well", you think, "I have tried everything" and give up. This is you measuring the input: you've done what you could, and even if that doesn't get the result you wanted, that's good enough. Then someone else just hides your friend's keys. You hadn't thought of that, and it's pretty hard to justify your input-centric view when you didn't achieve the goal and someone else did with the same resources.
So what happened there? I'd like to believe that you can always just focus on inputs, because they're the things you control. Trying to maintain control over the things you don't control sounds like a recipe for constant cognitive dissonance and unhappiness. But the problem is that, like in the drunk friend scenario, you don't always have a complete understanding of the input space. Unless you are certain you have a complete understanding of what decisions you could make and how to evaluate them, you can't rely exclusively on measuring input.
I think the right way to incorporate both elements is to avoid evaluating outputs, but rather measure your inputs, and use your outputs to evaluate your measurements. That way if your understanding of the inputs is incomplete, it will show up in your outputs, but you still won't end up judging your actions based on your outputs directly.