Tuesday, February 23, 2010

My environment

As I said before, I am distracted by hackability. I procrastinate by tweaking things. My programming environment fully reflects that I am the kind of person who finds config files a far more interesting form of entertainment than Farmville or television.

I've evolved what I consider the perfect environment. It is utterly hackable, completely inscrutable to the impatient and incurious, and it provides a rather more valuable avenue for procrastination than what most people would choose.

Here's my environment: Arch Linux, Xmonad, emacs, zsh, screen, uzbl, and conkeror. (Look in the sidebar for some of my dotfiles in github). In short, I can tweak anything, as much as I want, and never be absolutely done. 



The upshot is that my procrastination is guaranteed to teach me something, as well as putting more awesome in my day. The downside, as far as I can tell, is that I have no clue who or what Lady Gaga is without googling.


Make your environment hackable; it keeps you off potentially more distracting hobbies like black tar heroin.

Workflow.org

As part of my attempt to become more productive, I am trying out a new system of organizing projects.


I've limited myself to a handful of projects at any time. Each is within its own vcs'd subdir within ~/code. This keeps me thinking in terms of projects rather than languages, which is how I used to organize things. Hopefully, I won't be as tempted, upon figuring out foo monad in one place, to try it out somewhere else and end up spending hours down the rabbit hole. I know I'm not the only one to be distracted by his fascination.


Upon mkdir, I create a workflow.org file. It contains, simply, my guess of how the project will break down into manageable units. Think of XP's User Stories. At the start it will be chunky with lots of magic steps:

  • TODO IO monad for communicating with X safely
  • TODO ????
  • TODO PROFIT
Don't worry. Very quickly, it will become fleshed out as more subtasks are discovered, testsuites needed, packages updated, build environments automated, etc. Soon workflow.org will be a visible reminder of what steps have yet to be done, what steps still smell of "MAGIC AHEAD", and what your progress has been. Each C-c C-t will reinforce your sense of achievement, a minor cause for celebration. Feel discouraged? Look up its version history and see a visible reminder of how far you've come in figuring out that your project is a beast of complexity: "wow. I really didn't think that making this threadsafe would be such a bitch."


Can't say it will work for anyone else, but this seems like a good way to keep a sense of momentum on a project without complicating things.

zipWith

I've come to the conclusion that I shave too many yaks. I tend to go into broad hack mode, following tangents into deep waters without actually producing proportional results. My old ~/code was littered with projects half-completed, outlined, etc. I wasn't thinking in terms of "get foo to work" but "foo is interesting, I wonder if I can do bar as well?" This led to separate dirs for each language, full of separate projects and translations/ports and experiments.

One day, I decided to start anew. I archived all those odd starts and stops, and put them away with the metaphorical juvenilia where in an ideal world adolescent poetry would remain.

Starting from a blank slate is drastic yet liberating. I can already hear the objections, though:

"What about DRY?" someone will ask.

Well, have you looked at the code you wrote only a few months ago? Is it really repeating yourself to replace inadequate kludges with new and more sophisticated ones? If I wanted to strictly DRY, I would never bother refactoring. Consider a fresh start a de facto "you can do better than this. Rewrite it from scratch so maintainers don't hunt you down and stab you."