This post originated from an RSS feed registered with Agile Buzz
by Oliver Steele.
Original Post: Get Lost!
Feed Title: Oliver Steele on Software
Feed URL: http://feeds.feedburner.com/osteele
Feed Description: Languages of the real and artificial.
I like to travel in style. Two different styles, in fact: exploratory, and direct.
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.
1 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.