A Trifle Absurd

Trifle at the Turn of the Year

As the holidays wind down, I’m starting to think again about working on Trifle in the coming year—and hopefully shipping it. I’ve been working on a better description to put on the Trifle page. Here’s what I have at the moment:

Trifle is an application for organizing stuff, from task lists to web bookmarks to ledger entries. It’s built around four things: lists, entries, columns, and rules.

A Trifle document is a collection of lists. A particular entry can be on one or many lists (just as a single song can be on many iTunes playlists). An entry can be linked to a file or web page, or it can stand alone.

A list can be expanded into a table by adding columns. For instance, you could add start-date and end-date columns to a schedule-item list.

Rules let you make things happen automatically (e.g. whenever an item is added to list A, remove it from list B). They can be as simple as the filter rules of an email program, or as complex as a spreadsheet formula.

And that’s it. I’m still hoping for a late 2006 release, but as I get a better picture of the work involved, the schedule gets longer and longer. All that means (I hope) is that I need to cut some features from version one to keep things sane.

From Projects to Goals

My GTD head-slapper of the week was realizing that I can just ditch terminology that doesn’t work for me. In David Allen’s scheme, a “project” is “any desired result that requires more than one action step”. He emphasizes how even small things, like getting the piano tuned, qualify as projects. But when I think “project”, I think of something bigger, like creating Trifle.

My projects list has consistently leaned towards my own sense of what a project is. The result has been that little projects wind up on the next actions list, which leads to trouble, because it cancels out the benefit of having a list of simple next actions to work from. Quoth David: “[O]ne of the subtler ways many [people] fall off the wagon is in letting their action lists grow back into lists of tasks or subprojects instead of discrete next actions.” (GTD, p. 243)

So in an attempt to get my head into the right mindset, I’ve reviewed and rebuilt my lists, and renamed my “projects” list to “goals”. I’ll see how it goes; it seems dumb to expect much of a terminology change, but sometimes the oddest little things can make things click.

How I Got Into Computers

Inspired by Julie Leung, Nat Torkington has been collecting and posting stories of how folks originally got into computers. Julie’s husband Ted has also chimed in with his story. So I’ve been inspired to tell my own tale.

I fell in love with computers and with programming during the third grade at Tum-A-Lum School, an old, small school building that housed the second and third grades of Milton-Freewater, Oregon. I’d had a couple of brief run-ins with computers the year before (my uncle’s TRS-80, a Commodore PET), but the arrival of an Apple IIe at our little school was the real catalyst.

Yes, that’s right: one computer for four classrooms full of students. Mostly it sat unused in the school office, though occasionally it would be trotted out to give a demo for a class. But somehow—I’m still not sure how—I got special dispensation to spend time on the computer by myself.

Somebody showed me how to load Logo, and taught me a few basics; after that, I was left to explore it on my own. In some ways, I didn’t get very far: I never learned about Logo’s more advanced features, and I spent a lot of time reworking the same little programs. But in other ways, I learned a lot: that computers were decipherable, engaging, and fun.

The next year we moved to New Plymouth, Idaho. For some reason, that was Commodore 64 country: they had them in the elementary-school computer lab and at a computer camp I attended in a neighboring town. I started learning BASIC, and a few of the Commodore’s particularities, but of course had to snatch computer time here and there. But thanks to my uncle’s generosity (he of the TRS-80 I mentioned above), I soon had a Commodore 64 of my own.

That C64 was my workhorse machine through the rest of elementary and high school. I devoured computer magazines (along with huge quantities of orange juice), learning the ins and outs of programming. I had a subscription to Compute!’s Gazette, and eagerly scrounged old issues of Compute!, Byte, Ahoy, and all their kin. I also worked over the tiny computer section of my local library, reading several of my favorites over and over again.

The culmination of my C64 programming career came at the very end of high school, when I wrote a program to play Othello and sold it, with an accompanying article, to Compute!’s Gazette. It was published in December 1991 as “Desdemona” (thus sidestepping trademark troubles) in what was by then “Compute!, Gazette Edition”.

I’ve learned a lot more about computers in the years since, but these early experiences gave me a joy in computing that I hope I never outgrow. I thought I’d lost that joy in my post-Microsoft burnout, but now I’m having fun again.

Overleaf On Hold

I won’t be getting back to working on Overleaf for a while. I still think it’d be great to have an open-source programmable multi-language Cocoa code editor on the Mac, and I hope to help make one someday. But right now, two considerations hold me back: Trifle’s higher priority and XCode’s surprising adequacy.

The further I get into Trifle, the more tasks spring up—not just coding, but also the machinery of starting a business. If I want to ship Trifle next year, I need to focus on it near-exclusively. And there’s the bottom line: Trifle has a chance of making me a living; Overleaf doesn’t.

Now that I’m coding in Objective-C, XCode is a surprisingly tolerable editor. It allows proportional fonts (unlike TextMate), and it does fully automatic indenting (unlike SubEthaEdit). I wish it was faster, and that its syntax highlighting was more flexible, but in the end, it works.

A Coding Rhythm

A fun part of logging my time has been discovering little patterns in my day that I’ve never noticed before. Case in point: my coding sessions tend to last ninety minutes.

I’ll be completely absorbed in what I’m doing, but then I start getting restless. I suddenly feel like reading email or going to the kitchen for a snack. I look up at the clock to log the time—and it’s been just about ninety minutes.

I wonder if that’s always been the case. Did I do the same thing during a normal coding workday in my prior life as a developer, or in college? Or did this pattern develop as I’ve gotten a little older and less likely to go on an all-night coding binge?

Coding seems to be the only activity that gives me ninety minutes of sustained flow. Other activities (playing music, for instance) seem to top out at an hour or so. Maybe I should look for ways to apply the flow lessons of coding to other areas, like music and writing.