Getting Lost 1

Posted by Oliver on January 24, 2008

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.

Why Write Open Source Libraries

Posted by Oliver on January 24, 2008

1. Exploration. I can sample platforms and sample stretch languages without sinking my stakeholders if I fail. Also, it’s easier to try something radical in a small, green field project than in a big one.

2. Altitude training (link TBD). I can make myself jump through hoops that I wouldn’t feel ethical asking someone to pay me to jump through. I did this recently with Sequentially; the next time I needed to simulate concurrent processes in a more serious context, it was a lot easier.

3. Encapsulating components. My answer to Steve Yegge’s problem is to refactor my code into libraries. When I write programs that run on Linux, or the JVM, or a browser, I get those features, but the code sizes of those libraries don’t really count against me. Why not do that with my own code, too.1

This was the motivation for LzOsUtils and Fluently (both didn’t get to projects), most recently: they were part of other projects, but they were respectively large/tricky enough that I wanted to be able to compartmentalize them, and think about them separately.

5. The Golden Rule. I’ve benefitted hugely from open source projects; why not give back a little?

6. You can take it with you! I’ve written things that I want to use in more than one project; this is easier if they’re in library form. That was the motivation for LzTestKit (another didn’t get to project), most recently.

7. Fame and fortune! Just kidding. You get more fame from working on one project (if it’s the right one) for a long time. And there’s more fortune in straight consulting.

8. More days. I’m with Joel and Leo Babauta (ZenHabits): sometimes I can only work productively for four hours a day. The trick is to have more days. If I’ve got another project I can switch to when I burn out for the day on the first one, sometimes I can get another work day out of it. (Another trick for getting another day to move from the home to the office or vice versa, or to switch cafes.)

1 Interestingly, the extra work to some code up so that I never need to look inside it again (docs, test cases, examples) and can remember how it works years later is exactly the same work that I need in order for someone else to use it. I use to think I could take a short cut on things I use myself, but with enough going on or enough years in between, it isn’t true.

What Every Programmer Needs to Know About Category Theory 13

Posted by Oliver on January 17, 2008

The Programmer’s Food Pyramid 26

Posted by Oliver on January 17, 2008

Programmer's Food Pyramid

Update: (1) There’s a discussion (at the moment) on reddit. (2) Thanks to FusionGyro for suggesting the name change to “revising”.

Buy on Zazzle:
Poster
Mousepad
Coffee mug