Alex Payne

Writer, backer, erstwhile technologist.

RubyConf 2007, Day 2: Maximizing Productivity

Eric Hodel, an illustrious Ruby hacker with over 40 projects under his belt, is presenting on how he organizes himself for maximum time spent coding.

Hodel starts by choosing projects carefully and not reinventing the wheel. He claims not be a “coding superhero,” and breaks projects down into small, focused pieces. His acronym mantra: YAGNITAGAFI: You Ain’t Gonna Need It, They Ain’t Gonna Ask For It. It’s important to keep to a clear purpose.

Testing is essential to his process, providing a groundwork for new features and ease of contribution. Hodel is a fan of autotest, and prefers to keep his entire development process visible. His desktop is four terminals: code, autotest, and a couple of extra testing windows. Later in the development process, Hodel uses the heckle mutation tester to ensure his test cases are robust. Automation is a general theme.

Hodel suggests knowing your editor inside and out, although he doesn’t recommend a particular editor. Pair-programming is another suggested tool, including “ping-pong programming,” in which two coders go back and forth writing tests and coding to satisfy those tests.

Documentation strategies include a README with a quick-start guide, a synopsis and feature overview, and a link to the bug tracker. The bug tracker itself should be set up with categories, groups, and email, and disallow anonymous feedback to allow for follow-up. RDoc documentation should include examples.

Hodel gets feedback before releasing. When he’s ready to release, he uses the hoe tool to automate every step of the process, including uploading to RubyForge and making blog posts. Hodel suggests minor releases to make bug-hunting simpler, and then taking the time to relax after a release. “It’s no fun to code 24/7.” Amen.

Building a community around bug tracking is key. Beyond that, it’s worth searching beyond the bug tracker to find reports on mailing lists and blogs. Responsible bug submissions are stressed: include the steps to reproduce the bug, your platform, etc. Consistent versioning is suggested. Hodel uses a major.minor.bugfix convention, and bumps the major version when API incompatibilities are introduced. Generally, while he claims to “write a lot of crappy software,” he tries not to be concerned about complaints and to encourage contributions.

Hodel finds inspiration in hacking nights and solutions from other communities (ex: the Smalltalk environment’s test feedback, which inspired autotest). He also suggests writing pain-killers software that solves nagging problems in your work and life.