Also useful for moving a Frogger game cabinet without losing your high scores.

My answer explains a small nugget of GTD wisdom I’ve been able to distill over the past few months, and I’d like to share it with you here.

On Mon, Jul 20, 2009 at 2:20 PM, DerekS wrote:

I have been on and off the wagon several times with respect to GTD and have finally noticed that all the things I want/need to get to are just floating around and making my head spin.

I go in cycles as well, and every time I get a little closer to something truly maintainable. Let me give you a tip from my latest go-round:

Use the hell out of your Someday/Maybe lists.

Before you put something on an action or project list, ask yourself: when I find myself in the context to take action on this, am I really going to do it? Do I really care? Have I actually committed to doing this, or is it just something which seems like I might want to do? If you’re not truly committing to doing it as soon as you’re in that context, put it on your Someday/Maybe list.

I keep a few S/M lists:

1. Someday Soon: Things I’ve pretty much decided I’ll do, but I haven’t decided to start working on yet. I consult this weekly.
2. Someday Perhaps: Things I’m not sure I’ll want to do, but which I don’t want to forget about. I consult this one weekly too, but with a different mindset.
3. 40,000ft Options: Basically career paths which I might like to shift to one day. I don’t consult this one much, but it’s good to have a place to put those ideas.
4. Way Out There: Crazy ideas I’ll probably never do, but which, again, I feel better for having written down.
5. Movies to Watch, Books to Read, etc: a series of lists of media I’d like to consume. I consult these when I’m looking for a good book, movie, etc.

All this means that my project and action lists have no noise. They’re all things that I’m ready to do at a moment’s notice.

For this to work, the Weekly Review is critical. If you don’t trust that you’ll see these things as often as you feel you need to see them, you’ll instinctively put them somewhere where you will. That will probably be your action and project lists. Once those become cluttered with things you haven’t actually decided to do yet, you’ll stop trusting them, and then you’ve got nothing. I’ve been through that cycle numerous times.

I used to put off my weekly reviews for all sorts of poor reasons. Just schedule an hour or two every week at the same time and check your lists for inconsistencies. You don’t even have to think very hard. If you just read over your action, project, and S/M lists, your brain will tell you when something’s in the wrong place, or out of date.

You can get better at the Weekly Review over time, but only if you actually do it. It’s far more important to do it than to do it well.

If you don’t know, Pivotal Labs is an elite ninja squad of developers, trained in the art of Ekusupidō (also known as Extreme Programming). Pivotal, based in San Francisco, is growing their new(-ish) NYC office, and I’m proud to be joining the wonderful group of Pivots who work there.

Yesterday was my last day at drop.io. I worked there for just over a year, and it has been a wild and hugely valuable experience. When I arrived at drop.io, fresh out of college, I really didn’t know what I was doing. I thought I knew what I was doing, but I didn’t. A year later, I know what it’s like to accidentally bring down a popular website and rush out a fix. I know what it’s like to be clever with my code and confuse the hell out of my coworkers. Most importantly, now I can (usually) recognize when I’m about to do something stupid, and decide not to.

I owe drop.io a huge thanks. Thanks for taking on someone with so little experience, and thanks for letting me experiment while I found my dev-legs.

Yesterday, the team threw a little sendoff party for me. There was pizza, beer, and stories aplenty. Then Mike and Pete scurried off. When they came back, they were holding these:

I’m bowled over, guys. That is the best present ever. Though, as someone pointed out, it raises the question: can you wear a shirt with your own face on it?

A big thank-you to everyone at drop.io. I’ll see you on Twitter, I’ll see you on Foursquare, and hopefully I’ll see you at an upcoming Wet Sox game.

(Apologies if this post was a little inside whiffleball.)

When I arrived at Bard College as a freshman, I wanted to study Computer Science History. I had stories of Charles Babbage, Ada Lovelace, and Alan Turing bubbling in my mind. I wanted to learn more about where it all came from. What happy accidents and brilliant insanities had built on top of one another to construct our modern computational world?

No one would teach me the history of computer science, so I settled for what I could pick up on my own. Soon I discovered the computational pioneers of the modern era. I learned how Alan Kay created Objects; how his GUI at PARC inspired Steve Jobs and Apple to create the Macintosh, which in turn inspired Windows and set the standard for computer interfaces; how his Smalltalk inspired Objective-C and Ruby, which was also highly influenced by John McCarthy’s Lisp. I learned how Linus Torvalds and Richard Stallman built the two great empires of Free Software, Linux and GNU, living in symbiosis, and leading the way for the Open-Source Movement. I learned of giants, gods, and titans, and I learned that they were my ancestors. And then I realized something:

These people are still alive.

This still boggles my mind. These are great men and women of history, and they’re not dead yet. We can still go ask them questions. We can even work with them, learn directly from them. How lucky we are to live in an age of such rapid change that our Great Old Ones are still among us!

May we young grasshoppers be wise enough to seek their wisdom.

Corey Haines is touring the country pairing with all sorts of great programmers. As he’s travelled, he’s filmed a series called “Road Thoughts”. In his latest entry, Corey discusses the importance of learning and remembering our history. I think he’s absolutely right.

• Drag a story to the chat. Its URL will be added to the chat input box so you can say something about it.
• Click a story URL someone has posted to the chat. That story will be revealed in Tracker without opening a new page.

Hopefully these changes will make it easier to discuss Tracker stories in chat.

To install tracker_chat, install Greasemonkey in your Firefox 3, and then click here: Install tracker_chat

At drop.io, we’re in the process of moving from Lighthouse to Pivotal Tracker. Lighthouse is great for storing bugs, for searching them, and for maintaing a threaded conversation on each one. It works well for the open source development model. That’s basically what we used to do.

Now we’re moving to an Agile model. We create and deliver many small amounts of customer value, we work in an iteration-based rhythm, and we work together as a team, or at least we’re aware of what everyone else is working on. Tracker is perfect for that workflow. But this isn’t a post about how awesome Tracker is. This is a post about how I made it a little more awesome.

We all sit in chat all day, and naturally we use drop.io as our chat service. It works really well, because when it doesn’t, we fix it. I usually keep it up on my laptop screen while I work on my external monitor.

But Tracker updates itself in real time, so it’s nice to keep it up all the time too. So now I want to have it on my laptop screen.

Now I have both.

Requirements

• Firefox
• Greasemonkey

To Install

1. Navigate to the script.
2. If you haven’t created a drop to chat in, create one at drop.io. (One click, no signup.)
3. Go to your Tracker project.
4. From the Views menu, choose “Chat…”.
5. Give it the name of your drop.
6. Enjoy!

GreaseKit

Unfortunately, tracker_chat doesn’t work perfectly in GreaseKit. The chat will appear in Tracker, but with the full chrome you’d see if you viewed the chat normally. In Firefox/Greasemonkey, extraneous chrome is hidden to save as much real estate as possible.

More Info

Check it out on GitHub at http://github.com/Peeja/tracker_hacks.

One week earlier…

Every Tuesday we start the day with a full-team meeting which we call a scrum (though it’s not quite a real scrum meeting). At last week’s scrum, Sam and Jacob introduced our new development practices:

• We operate in two-week cycles (or iterations).
• There are four areas of development to work on.
• Each cycle is dedicated to working on one of the four areas.
• Stories are written on the board.
• To claim a story, a developer puts their name next to it.
• When a story is complete, it’s erased and put on a piece of paper, which is taped to the “Ready for Staging” area.
• When a story is deployed to staging, it’s moved to “Staging”.
• When everything in staging has passed QA, we can deploy to production.
• When a story is deployed to production, it’s moved to the production wall.

That’s about it. Now there’s a lot about Agile that’s not here. There’s no story estimation. There’s no iteration planning. Stories can be added mid-iteration (and often are). The product owner role is almost non-existent. The developers implement stories in the order they choose.

But it’s a start. Even this much is a huge change for us, and a very welcome one. It’ll be a while before we’re comfortable enough to wade further in, and I’m ok with that. We’re learning every day about how to make this work.

We’ve included the most important element of Agile development, however: regular retrospectives. As long as you review your process and your progress regularly (and honestly), it’s hard to go wrong. Over the next few months I expect we’ll rapidly adopt even better practices for our team as we discover what those are.

Next week I’ll write up how our first retrospective goes.

class Car
  def go_forward
    # ...
  end
end

class Convertible < Car
  def door_count
    2
  end
end

class Sedan < Car
  def door_count
    4
  end
end

How would you write Car#doors? You wouldn’t, because unlike moving forward, that behavior isn’t shared across all cars. Car is an abstract class: a class that should never be instantiated directly.

But what’s stopping us? Nothing. And that’s a problem. So let’s fix it:

$ sudo gem install abstraction

Then:

require 'abstraction'

class Car
  abstract

  def go_forward
    # ...
  end
end

Car.new
#> AbstractClassError: Car is an abstract class and cannot be instantiated

But:

Convertible.new  # => #<Convertible:0x8fdf4>

Awesome.

Awesome? Why so awesome?

Ok, let’s take it back a step. You’ve got a Car class with no subclasses. They haven’t been necessary, and you don’t want to add complexity you don’t need. Good for you.

class Car
  def go_forward
    # ...
  end
end

Cars go forward, and that’s about it. Except, now some parts of the code want to know how many doors a car has. Remember, that depends on the kind of car it is, so we’ll need Car to know about its type. And since convertibles are pretty rare in your code, you have cars be sedans by default.

class Car
  attr_reader :type

  def initialize(type=:sedan)
    @type = type
  end

  def door_count
    case type
    when :convertible
      2
    when :sedan
      4
    end
  end

  def go_forward
    # ...
  end
end

Pretty soon you realize its time to refactor this puppy. You want a refactoring called Replace Type Code with Subclasses. What you end up with is the set of classes we saw at the beginning:

class Car
  def go_forward
    # ...
  end
end

class Convertible < Car
  def door_count
    2
  end
end

class Sedan < Car
  def door_count
    4
  end
end

The problem is that all of your tests are passing, but none of your code is using the subclasses yet. You could probably grep or ack through your source to find all of the times you use Car.new; in fact, you should. But you should still be testing that you’ve done it right. Also, if Car is backed by an ORM, it might be creating Car objects for you.

But as we’ve seen, Abstraction clears that all up. Just make the class abstract…

class Car
  abstract

  def go_forward
    # ...
  end
end

…and watch your tests fail. When they pass again, you’ve completed the refactoring.

Abstract Methods

(Warning: this section is a bit of a tease.)

Traditionally, abstract classes are found in strongly typed languages, where the compiler makes sure they’re never created by type checking. In the Ruby world, the test suite is essentially our type checker. No complier can statically prove that an abstract Ruby class will never be instantiated, but we can exercise the test suite and see if it ever happens.

Abstract classes usually have a way to notate abstract methods. These are methods which are declared in the superclass, but don’t have an implementation there. A concrete subclass has to implement all of the abstract methods. Again, this is checked by the type checker.

We have an example of an abstract method above, it’s just not denoted in any way: #door_count. Similar to the case of abstract classes, we can’t prove statically that abstract methods are implemented in the concrete subclasses. We have to run the tests and see if they’re defined when they’re called.

But: if they’re called and there’s no implementation, we’ll get a NoMethodError anyway. The declaration of an abstract method in the superclass is really only useful to the type checker, to tell it that, for instance, any Car object has a #door_count method. We don’t have a type checker. So we don’t need to declare abstract methods.

But wouldn’t it be useful?

It would be, if it were meaningful. The problem is: what does it mean to implement a method? In Ruby you really can’t know whether a method is implemented until you send it the message and see if it raises a NoMethodError. There’s no way to determine whether a class “implements” all of its superclasses abstract methods without making assumptions like that the class doesn’t use method_missing or that instances of the class won’t get their own singleton implementations. And the nail in the coffin: there’s no time when a Ruby class is done being implemented, so there’s no time to check.

On the other hand, maybe there’s a way to make it useful. If there is, it certainly belongs here, so drop me a line or just fork away.

Where’s the Code?

Grab the source from the GitHubs. Pull requests more than welcome.

So I tried it. Chris sits next to me, and we often show each other what we’re working on, so pairing with him seemed natural. It turned out he’d been curious too. We started on Monday, and now it’s been a week. So what have I found?

It’s all true. We blew through huge amounts of stuff. When you’re working with a pair, you can’t check your email every five minutes, or read Twitter, or watch YouTube videos. You stay on task. If one person gets up to get some water from the cooler, the other person can keep going. You catch all sorts of mistakes. I found these usually weren’t things which would become bugs, but they would have given us weird failures and taken longer to track down if we didn’t catch them immediately, like typos or forgetting to change the name of a method in one place.

Most importantly, though, we talked. When you’re working by yourself, it’s easy to just code and not think about how much time you’re taking to futz with a Rake task or implement a design pattern until— I’m late! I’m late! For a very important date! And as your deadline whooshes past you wonder where all the time went.

Working with a pair was different. We talked through everything as we did it, which meant we saw issues before went down rabbit holes. I felt extremely effective.

But there’s something else they say about pair programming, and it’s true too. It’s exhausting. Remember, you’re working full-steam, no futzing. It’s great while you’re doing it, but it’s easy to wear out. Always take frequent breaks when you’re pairing. You’ll still come out ahead, and—more importantly—you won’t keel over and die.

We also learned that some things don’t go well with pairing. Chris, being primarily a front-end guy, does a lot of styling and design. His CSS skills were useful in our pairing project where we touched the full stack from models to views. However, he’s working on some other things which are just design. Pairing there didn’t do much for us; it was mostly me watching him work. Pairing seems to work better when there’s more logical thinking to do.

We also found that the driver/navigator approach to pairing didn’t work well for us. Corey Haines in his (awesome) talk at Philly ETE said he preferred to give each person their own keyboard and mouse. That worked best for us too. We could switch typers rapidly, without moving the keyboard around.

Pairing is a habit. It is, I think, one of the Good Habits of Programming. Like TDD, it feels weird at first, then helpful, and eventually necessary. I can still code without a pair, just as I can code without tests, but why would I want to?

1. Use Leopard’s Screen Sharing.app,
2. Use the screen sharing built into iChat, or
3. Use a normal VNC client.

Screen Sharing.app lets me choose which screen I share. That’s important, because I have the two screens. In a normal VNC client or, curiously, in iChat (which shold know better), I’m forced to view both screens at once side-by-side, which makes them each quite tiny.

However, Screen Sharing.app lacks a full screen mode, which makes it hard to work in. Since I’m working solely on the remote machine, I’d like to have it take over my display entirely. iChat does full screen, as do many VNC clients, but they don’t let me choose a screen.

I’ve found an inelegant but passable solution. Ian Handerson has written a nifty little SIMBL plugin called Megazoomer. In any window, pressing Cmd-Return will “mega zoom” it to fill the screen. Inside Screen Sharing.app the keystroke gets swallowed and sent to the remote machine, but you can still use the “Mega Zoom” menu item in the Window menu.

The best way to install it (you can ignore Ian’s instructions; they don’t work as well in Leopard) is to first install PlugSuit, a handy preference pane for managing hacks like this. Once it’s installed, open up PlugSuit in your System Preferences, and drag Megazoomer into the Extenders list. Relaunch Screen Sharing, connect, and choose “Mega Zoom” from the Window menu. Fullscreen glory.

You’ll notice that it’s not quite perfect, but it’s good enough for what I need. For best results, adjust the remote display’s resolution to but as close to but not greater than your local resolution as possible.