It's kind of definitionally true that you can't change the past, and it really saves a lot of anguish to stop trying. Caring about the past is like caring about the rotation of the earth or the speed of light; it's so far beyond your control as to be meaningless. But there's no equivalent statement about the future. You can change the future, and depending on the situation it can be either easier or harder to change things the further they are in the future. Easier because your efforts can multiply together over time (like saving money), and harder because other factors also multiply together (like predicting weather).
But it seems so strange that there's only one moment when you can actually make a change. Sandwiched between an unimaginably large number of moments in the past and an infinite number of moments in the future, there's only one moment that's the present. And it's so small that it's hard to even define. All of your thinking and planning counts for nothing unless it reflects an action in that single moment. All that pressure concentrated on a single point in time.
And an instant later it's meaningless, and you start over.
I put together a neat demo of my "context table" idea. To make more efficient use of letters I abbreviated it to Contextable, which also his the nice side effect of being meaningful outside of being installed under an actual table. A brief recap: the idea is to display relevant results from Wikipedia as you talk.
To solve the problem of which words or phrases are meaningful enough to display, I actually ended up using a pretty nifty technique involving Bloom filters. I built a big filter of the million most popular pages on Wikipedia, cut out some common stop words and used that to determine what's worth loading from the Wikipedia API.
I pick an arbitrary phrase size (4, in this case), and look up the next 4 words in the input. If I don't get a match, I try the next 3 words and so on. This means that I get more specific results: "Super Bowl Sunday" instead of "Super Bowl" and "Sunday". Doing that many requests to the API would be way too many, but the Bloom filter can easily handle lots of lookups quickly.
If you're curious, the source is on GitHub. Happy contexting!
It's pretty interesting that open source projects don't recruit the same way commercial projects do. In a company you usually have particular people responsible for going out and recruiting employees, advertising the availability of positions and so on. But the only time I think I've seen a similar thing is from companies like Mozilla or Red Hat who do commercial open source, and their recruitment is just for the commercial side. For an open source project, usually you get involved by just turning up on your own initative and submitting some code.
Interestingly, commercial open source companies often take advantage of the benefits of the open source way. An open source contributor already has to show a degree of initiative in showing up and demonstrate ability by sticking around and having their contributions accepted, which is a reliable signal that the person in question would be a good hire.
But I think the open source community would be a lot more robust if it embraced some of the benefits of traditional hiring. Recruiting lets you specifically target certain people and certain roles that are under-served, and advertising for open source contributors would pull in a lot of people who otherwise wouldn't have considered the project, or even open source in general.
I suspect recruiting might appear to project maintainers as one of those "we don't play that game" type things, or perhaps they've just never considered it. Either way, I think adopting some more traditional recruitment strategies could be a serious benefit to open source projects and the movement in general.
When I do something, I usually think of it as either work: something useful, something that creates value, helps people, or causes me to be closer to my goals, or play: something enjoyable, something that lifts my mood, brings me happiness and helps to restore my energy and motivation. In an ideal situation, I can do things that are both work and play, but one thing I've learned is that it's unrealistic to expect that all the time. Even for things you really care about, there are some parts that are all work and no play.
But there's a much more dangerous category of activity, which is no work and no play. These are things that you thought were going to be useful work, but slowly turned into useless work. Or things that were fun, but slowly stop being fun and eventually just become big time sinks. At that point, you're usually doing a no-work-no-play activity out of obligation or habit, often without really considering why you're doing it.
Pruning those activities out is a surprisingly liberating experience.
I was talking to a friend today about package managers and it reminded me of one of my favourite pieces of software: the Australian e-tax system. It integrates with about ten different awful government backend web services. It's built on some nightmarish HTML-meets-Visual-Basic-form-builder framework. It has, embedded in its hellish code dungeon, all of the various zillion arcane tax rules and things. In many ways, it is the grossest, most awful thing ever created. Yet I like it. Worse still, I respect it.
Paul Graham talks about schlep blindness, the tendency for startup founders to avoid complicated and unpleasant startup ideas, or even unconsciously filter them out before even thinking about them. I think there's a similar thing for code. There are certain kinds of software problems that are absolutely glorious to solve. Problems that, by the judicious application of the right algorithms and clever design, become completely solvable in a way that is elegant and satisfying.
Unfortunately, most problems that actually matter to people are only part elegance. The other part is all of the extra stuff that takes way longer than it should, that involves badly specified problems, arbitrary constraints and meaningless plumbing of data from one place to another. In a word: suck. The holy grail is to live in a world with no suck, but that world is very crowded. So what about going the other way? Embrace the suck and look for the least elegant, most complex, most unsatisfying class of problems. Maybe there's some seriously overlooked value there.
The example in question: I think we'd all be better off with a universal package manager that works everywhere, and can install things in any programming language. But there's no way to get something like that off the ground; people won't give up their existing package managers and trying to get everyone to agree on a new standard will never work.
But one thing that could work is going deep, deep into the valley of suck, and returning with a system that includes every other package manager's special formats and quirks in one horrific bundle. So it talks to npm for Node packages, talks to PyPI for Python packages, talks to the various apt servers, and knows how to manage each individual package format's expectations about how installing works, deals with conflicts between the packages... I mean, ugh, that is one profoundly sucky problem space. However, I don't think there's any other way to make progress there.
I can't find it now, but I remember seeing a really impressive exchange on the Chrome bug tracker. Someone was complaining about the way Chrome switches to another tab when you close an old one, and they said "this is just going to lead to more and more special cases". The developer replied "that's fine, we're trying to capture people's expectations and those involve a lot of special cases, so we'll just include them all".
What an idea! Just include every special case. My instincts were screaming about how awful that would be, how unbounded the suck. But they did it, and it works great. I don't know how Chrome chooses to switch tabs when I close them, but it matches my expectations, whatever those are.