We’ve gotten to that QA stage in the project where for the last several days all I’ve done at work is fix minor typographical errors and, like, the alignment of columns in tables.
Somehow, that’s not too exceptionally stimulating. Particularly when the errors are all in bits of code that I had no part in writing. Fixing a small thing becomes a painful ordeal - search through the code to find out where the errant bit is (keeping in mind that each developer on the project does everything differently, so there’s no real consistent pattern to any of it), make the update, fire up the app and verify the fix, then do the “paperwork” of filing the defect resolution and such in the defect tracking system.
All that means a 15 second fix takes half an hour.
In the meantime, my mind is totally wandering because it’s about as exciting as data entry. There’s no problem to be solved, there’s no new code to write (and in many cases, it’s not a code fix at all, but a resource file fix - so it’s updating XML, not code).
I’m having a pretty difficult time. I think it’d be a little better if I was fixing defects in my own code, but I’m not - it’s other peoples’ stuff. (At this point there are no open defects filed against my stuff, otherwise I’d be doing those.)
As I go through this, I’m realizing that once a problem is solved - even if the code isn’t totally written - I’m done being excited about it. My fun is in solving the problem. Sometimes that ends with the solution architecture. Sometimes it involves coming up with a slick way to implement the thing. But the nitpicky stuff - no joy there.
Now, that said, I’m almost as big on closure as I am on problem solving. I like finishing things. When a significant module is done in a project or when the project is done, I’m pretty stoked about it. That drive for closure gets me through the rote parts of the bits I’m working on.
The problem I’m having here is that fixing typos neither offers problem solving nor closure.
Perhaps I am not caffeinated enough. Maybe I should address that.