Thoughts on Systems

Emil Sit

Oct 20, 2011 - 2 minute read - Hacking e-mail git gradle make reproducibility workflow

Rules for Development Happiness

Inspired by Alex Payne’s Rules for Computing Happiness, some rules for having happy developers and being happy as a developer.

  • Use version control. (See The Joel Test.) In particular, use a distributed version control system (like Mercurial or Git). This ensures you can commit offline and also conduct code archaeology offline.
  • Have a correct and fast incremental build (e.g., non-recursive Make or Gradle) to avoid this.
  • Have a system for testing your changes in a safe environment prior to code submission.
  • Avoid dependencies on system tools. Different developers tend to have different systems and hence different versions of tools.
  • Be able to work offline. Offline may mean when you’re on a plane, but it may also happen when the office network goes down. Both happen. Notably, the latter happens even when you work on a desktop with a wired connection. (It’s been pointed out to me that the network going down can be a good team-building experience.)
    • Be able to build offline. That means having all build dependencies cached locally.
    • Have all e-mail cached locally. Don’t be unable to find those key instructions some mailed you just because GMail is restoring your mail from tape. Helpful tools here are isync or offlineimap. Index your mail with mu. (Or configure Thunderbird/Apple Mail/etc to keep everything offline.)
    • Be able to send mail offline; e.g., have it queue locally for deliver when the network comes back. But, make sure you keep a copy locally in case the hotel’s WiFi is transparently re-directing out-bound SMTP connections to /dev/null. (This really happened to me.)
    • Have other documentation cached locally. (Use something like gollum for your wiki.)
    • If you work somewhere with a shared-storage home directory, make sure you can login when the network is down!