29 April 2009

5 Minute Send

There is something that happens in my mind when (and only when) I push "Send" on an email.

This mental process says "oh, I wonder how it will look when they get this email". So then I go back and look at the email from a completely different perspective -- from the perspective of the recipient. Everybody has a "missed attachment" feature or plugin. But nobody has a "missed idea" feature or a "missed stupidity" feature.

I wish all the email clients I use (gmail, outlook, other webmail) had the following two features:
  • "Send" (on a draft message) which means: send in 5 minutes
  • "Send All Pending" (on a global menu, not on a message)
Then I could get the benefit of focused authoring *and* self-review when I press "Send" and think "oh, what have I just done".

P.S. I really like blogger's "Post date and time" feature, and I use it all the time.

28 April 2009

Nice benefits of git

I use git now and it saved my bacon last week. Two things made a really hard, late-breaking change possible:
  1. Ease of integration enabled parallel development.
  2. Smallness of commits meant easy bug isolation.
Ease of Integegration => Parallel Development
Because of the ease of integrating small commits, my coding companion and I were able to develop two complementary sets of changes in parallel. This saved us quite a bit of time because we didn't have to wait for each other. The changes were developed as a last-minute response to a problem right before release, and without the ease of integration, it would have been hard to get the problem right on a compressed schedule.

Small Commits => Easy Bug Isolation
Also, because commits are so small (because it's easy to commit without any side-effects, because your repo is isolated from everything else), it was easy to isolate the exact changes that caused a subtle problem. I could have used bisect, but I had an inkling which change caused it, so that was faster. With svn or a mongo patch accrued over multiple changes, it would have been much more confusing and disorienting.

27 April 2009

Revert by Commit

Here is a sequence that happens to me regularly:
  1. Have a theory about how to fix something
  2. Try it out
  3. Find out it was a stupid theory
  4. Realize that there is a kernel of learning in what you tried
  5. Realize that you don't want to throw away that kernel of learning quite yet
  6. But want to get the bad changes out of the way
  7. But there are some good uncommitted changes you don't want to throw away
  8. Ack, what should I do now?
Here is a recipe that makes it really easy to save the bad experiment *and* get it out of the way in ONE step.
  • git checkout -b experiment-that-stunk
  • git add -i (pick the one or two files that contain the changes you want to get rid of)
  • git commit -m "tried to do something stupid, but it didn't work because ..."
  • git checkout stuff-i-was-working-on
Revert by commit. Now the changes are gone, saved, explained, pickled for fermentation for more ideas or conversation.

That is something that was NOT part of my experience before git.

Actually, I take that back, I did this once or twice before, but I wasted lots of time because I resisted give up on the experiment at the first sign of stupidity -- I subconciously knew it would be painful to save a whole patch, partially revert, hope I got it right, forget what I was doing, mess it up, revert all the way, re-apply the patch, repeat. So it took longer to abort the bad experiment because of the hesitation because of the perceived expense of partial revert.


I just realized this must be how "git stash" is implemented, and that it's definitely not a new idea.

01 April 2009

Software Architecture

This is what I hate about overreaching ideas and projects that accept them:

The whole "coming soon" idea is fine if it lasts for a couple days, but years and years?

Now I'm hanging my head in shame about www.sumsion.org. :)