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
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.