Experience can mean contact with facts and events; or, the knowledge and skill that this contact causes. One sense measures the past; the other, the present. It’s the fact that one word has both senses that can allow one to describe the same life history as either “thirty years experience”, or one year of experience thirty times.

But even in its second sense, “experience” is a proxy measure for an unknowable: knowledge and skills that will be useful in the future. To the extent that the future resembles the past, it’s a perfect proxy; where they diverge, the correlation drops.

As a hiring manager, if I were to hire someone to do a specific job and they had done that same job before (in the same kind of organization, with the same tools, and the same requirements and constraints), and I only needed it done the same way, I might look no further.

I’ve never hired for such a job, so what I’m usually more interested in is “experience per unit time”: the efficiency with which a candidate converts the first kind of experience (contact with the world) into the second (knowledge and skills). This is because I expect the candidate to encounter new facts and events, and to need to use these encounters to create new knowledge and skills.

Age is a factor here: not because of the merits of youth for its own sake, but because it shows up in the denominator. If the ability to process life into knowledge and skills were all that mattered, then someone who had seen twenty years of experience (in the first sense) would need show at least twice as much experience (in the second sense) as someone who had only seen ten. This isn’t an advantage of youth, unless you’re comparing candidates with equal experience.

In a democracy, selecting a leader is like hiring an employee: specifically, a manager, or a CEO. (Or in some ways like hiring a contractor, because you can get rid of one by letting the contract run out; it’s harder to get rid of a bad employee .) The same criteria — motivation, ability, character, ethics, knowledge, interpersonal skills, management skills, communication skills, ability to process information and make decisions — apply. Experience, and the ability to acquire it, are important parts of the picture.

When I’m late to an appointment, I take the most direct, familiar, route I know. I don’t try any tricks — roads that vaguely ring a bell, or look like they might connect — I stay with what I’ve known.

But when I’ve time to spare, I get lost. Given a choice between a 15 minute route I know, and one that might take twice as long, I’ll take the road less traveled (by me). I’m paying for knowledge, with time.

I discover a lot of good routes this way — not always to the place I was going at the time, but often to somewhere I want to go later, when I’m in a hurry and wouldn’t have time to look for them. And, when I am in a hurry and I do get lost — because I’m coming from or going somewhere unfamiliar, or have to detour — I’m more likely to come across a place I recognize, and place myself back onto my mental map.

So maybe it’s too simple to say that I’ve paid for my knowledge with time. I’ve made a deposit (of time), that I can withdraw later. Knowledge is the loan note.

The same holds in programming, and project management, and software development. (These are some areas that are open-ended but set against a virtual landscape, and with which I’ve some experience.)

Often, as developer and project managers, we’re up against deadlines. Crunch time is not the time to risk something new.

But the rest of the time, it helps to take the detour, so that the next time you’re in a hurry and need something (a library, a technique, a language, a framework), you can remember where you saw it.

It helps to stay a little lost.

¹ Neither is when you’re working on someone else’s dime, unless it’s your employer’s decision. (Doing this from time to time would often be a good decision, but it’s rare.) This is one reason I write libraries.

One of the geek games you can play on an airplane is stretching out the battery life of your computer. I have enough batteries to last me through a six-hour flight now, but old habits die hard.

Since I save my files every minute or two, spinning down the hard disk isn’t an option. (I tend to use programs that communicate use the file system to communicate. And I don’t want to be in a position to lose more than a few minutes of work anyway.) I don’t usually use a CD or DVD player, so I’m already optimizing there. The CPU that I’m using steps down to 800MHz when the plug is out, so that’s taken care of for me. That leaves screen brightness.

The problem with turning down the screen brightness is that this also turns down my reading speed. I’ve noticed that I read a lot faster when I’m reading higher-contrast text. Since I already use black text on a white background, the contrast is proportional to the screen brightness (as long as the overhead light is off).

This effect matters most when I’m reading English. When I’m reading math or code, or writing anything, my word recognition time, which is the part of the pipeline modulated by the contrast, isn’t the bottleneck anyway — in those cases I’m limited by comprehension time, or by other central abilities. So I used to turn the brightness up when I’m reading, and turn it down the rest of the time.

Let’s call this the contrast modulation strategy. It trades off reading speed against battery life, based on the current activity (reading versus other work). The contrast modulation strategy works if I’m spending long stretches of time reading, or not-reading. It’s a pain if I’m going back and forth — referring to one document while I’m writing another, for instance.

Here’s today’s discovery: my reading speed is also proportional to the text size. I just ran a few informal comparisons, and setting my document zoom to 200% at the lowest brightness works just as well as turning the brightness all the way up. (With a large font, it doesn’t seem to matter how bright the screen is, at least within the range that my screen adjusts to.)

With larger text (a larger font size, or a greater zoom), I have to scroll more, but when I’m reading English I don’t need to see more than a few paragraphs for continuity anyway. When I’m reading code I want to see as many lines as possible (this one reason I prefer concise programming languages, so I can see several different levels of structure without having commit as much to my mental buffers so that I can scroll) and technical documents always seem to refer to tables and figures a page away, which makes for a lot of scrolling, anyway. So I want big fonts for English that I’m reading, and small fonts for everything else. But font size, unlike screen brightness, is something you can associate with a specific document.

Let’s call this the text size modulation strategy. The text size modulation strategy trades reading speed off against the amount of the document that’s simultaneously visible. The text size modulation strategy takes decouples the trade-off between reading speed and battery life and, unlike the contrast modulation strategy, it’s automatic once you zoom your documents, no matter how many times you switch between them.

I’ve gone back and forth since then between working on 2D computer graphics (at Apple Computer, Method Software, and my previous company AlphaMask, whose software is now used in the OpenWave mobile phone software platform) and computer language design and implementation (also at Apple Computer and Method, and at Linguomotors where I designed a language for describing natural-language grammars). In my current position, as Chief Software Architect at Laszlo Systems, these come together: I am responsible for LZX, a domain-specific language for writing rich internet applications. I’ll have a lot more to say about that later too.

I direct most of my time towards my work at Laszlo, and my family. In between these, I intend to update this blog every week or so.