careful prep for a code review
Yesterday and today, I think I stumbled upon a good structure for getting several simultaneous high priority bugs approved for checkin together. Think of the changes as orthogonal; make a new changelist for each bug you're fixing. For each changelist, make sure that it fixes the bug. Then do diffs on your files against the most recently checked in files. For each line of diff, look for fixme's and todo's. Can you clean up some bad spacing or improve a comment? Once you're proud of every line you've touched, build and run one more time. If all is well, ask for a reviewer. Then it's straightforward: "To fix this bug xxx, I made these changes in widgviewsnow.lzx." You can present the change with confidence, because you know what you've done and why. Those are fast, fun code reviews; resolving half-dozen P1 bugs in the space of a few hours.
But before all of that comes the real work of finding and fixing the bugs. Lately it's been working for me to do serious coding from hoome at strange hours. When I'm in the office, I'm available for communication and interaction, but I can't generally count on getting much real focused work done at work, lately. Thus: code hard evenings and weekends. Present focused checkins for review. Be available to work with other team members. Surreptitiously borrow team members windows machines in order to install Firefox 1.5 and trillian and openoffice and cygwin.