I love vim. I love gVim even more. I am very, *very*, fast in vim. In fact, I write all these entries in vim.

Now look at Xcode. Xcode is slick. I can do a lot of fancy IDE things in Xcode. I don’t work quickly in the Xcode editor. I probably write/modify code in Xcode at about 20–40% of my peak speed. I depend on Xcode for debugging, organizing all the UI stuff, and so on.

How does one marry the two in a way that does not suck? I would like to know where I can find helfpul hints about workflow when using Xcode and vim (even if it’s purely anecdotal). I may have to just break down and set vim to run xcodebuild at the command prompt with some keystroke, which should work well enough.

I often hear about how important it is to run daily builds. Since I have my source tree in a state where I can check out a clean copy and build it, I decided to turn that process into an automated script. I created a cron job (Oh how I love the UNIX underpinnings in MacOS X) which runs the build script every morning at 6am. The result of the build (if unsuccessful) will come via e-mail. I first check my personal e-mail every morning around 7:00, so I’ll know if something went wrong fairly soon after the build is done.

Since I do not have an automated process that packages the result of the build (yet), this script really only checks to see if the source didn’t compile and link. I don’t think I’d be silly enough to check in something that didn’t build, but now I can be sure that my script is making sure of that.

Today, I’m going to try and add a few more unit tests to my collection. Once I package up all my unit tests (which are too few and useless right now to warrant running on a regular basis), I plan to run them as well during the automated build.

Picture this scene: You get home from work, eat dinner, and sit down at your machine. At best, you have an hour to spend working on your part-time software endeavor.

What do you do?

Here’s my answer: I fix bugs. More specifically, I fix the bugs that I know will only take me 10-20 minutes to correct.¹ These bugs range from actual defects in the software (easily reproducible crashes, malformed data, etc) to behavioral deficiencies (”remove the calibration button from the main window”, or “the save file dialog should be a sheet, and not a seperate window”).

If I sit down at the keyboard with zarro boogs in the bugzilla database, then the job changes. I replace the task of fixing bugs with finding bugs. It doesn’t take very long before banging on your software will produce some entries in your bug database. Dedicating a half an hour to an hour of solid QA work on a regular basis will pay itself off with a wide variety of issues you should look into. Once you get to the point where an hour doesn’t yield any bugs (or feature additions), it’s probably time to release. ;)

What I’ve noticed so far, is that when I plan to spend an hour fixing one (or if I’m ambitious, two) bugs during that session, I often end up fixing those bugs much more quickly than if I dedicated a half a day to the same bugs. My mind appears to understand the constraint that these tasks must be completed in a limited time, and it seems to go into warp speed as a result. This is not hurried development, either. I actually perform more productively than when I give myself more time to work on the project.²

Furthermore, working on these notoriously menial tasks is far more productive than doing nothing. I can remember a time when I would sit down at my machine and get frustrated with the fact that I couldn’t add a new feature in the limited time I had to work on the project. That would result in deviating from working on the project entirely and doing something else. That is probably one of the many reasons why most of my past projects have not gone very far, and you have likely never heard of them. Taking these small steps towards a greater goal will eventually add up to achieving the goal.

I’m sure there are probably other factors that could contribute to this accelerated productivity I am experiencing in the limited chunks of time that I have. Some people procrastinate for similar reasons, claiming they “work well under pressure”. I think I sometimes fall into that train of thought, but I am trying to cultivate that behavior for this project and make it work for me. Hopefully I can keep it up long enough to get a good portfolio of (solid, maybe defect-free) software out in the wild.

¹These types of bugs are often called LowHangingFruit.
²See Steve Pavlina’s well-written article for a similar anecdote, and a more in-depth discussion of increasing productivity.