I was inspired this morning to read John Nunemaker’s recent post Improving Your Methods. John’s articles are always interesting (I’m also a big fan of his I Have No Talent post). The “Improving Your Methods” touches on always improving your efficiency as a developer.
In that spirit, I thought I’d share a little of how I focus on improving. As fair warning, these are obvious to anyone who takes the time to think about it. The problem is that too few take that time.
You can’t improve what you haven’t identified as inefficient.
As I’m going throughout my day, I notice things that feel annoying and cause friction (maybe it is too many key-presses or something feeling too slow). At one point I would have just clenched my teeth and moved on, but now I try to quickly jot the problem down to circle back to it later when I have free time. The interruption is minimal and using this method I’ve created a pretty thorough list of things that cause friction and should be eliminated.
Treat your fail lists like pending specs. Documenting your points of failure and friction are just going to be monuments to frustration if you don’t take the time to find ways to conquer them. I try to go over my list every weekend. At PatientsLikeMe we have a WTF List that we go to when we take a “Tech Week” (typically after every 2 sprints).
You should keep your “Know your fail” items in front of you. They should be in your face reminding you that you could do better.
As an example, I’ve been frustrated for awhile with a problem similar to the one John mentions in “Improving Your Methods” – our app is too large for things like watchr or autotest to be very helpful. Furthermore our test suite is huge and takes awhile to run. How can I know that when I work on a feature that I’m running all the related tests?
At first, I wanted something like cucumber tags for our other tests, but then I realized that in most cases I could accomplish what I wanted with a simple search. So I whipped together this script:
I’ve aliased it and it sits in my app root. So when I’ve completed some work on the transplants feature, I can just run “st transplant” and know that any test file that mentions the phrase “transplant” will run.
This gives me the confidence of knowing that I’m being exhaustive in my testing and saves me the trouble of trying to reason through which tests might be relevant.
I can’t close this out without mentioning my current brain-dump: Vimwiki. It is always just a few keystrokes ( <Leader>ww ) away from capturing any fleeting thought. I keep a special page for my “Know your Fail” items. It also features a simple journal/diary feature and a good-enough todo list feature. More than anything, it allows me to document things to revisit but still stay in my editor and on task. If you’re using Vim, you should surely check it out.