In software engineering it’s common to spend much more time understanding and characterizing something than actually implementing a feature or fix. For example, we just spent almost two hours pair programming to figure out 1) if the observed behavior is correct by design (yes); 2) why the error message is wrong (null set); 3) finding where in the code the message is being reported (line 1769); 4) typing “if !=NULL” in exactly the correct place, without disturbing any surrounding code; 5) testing the change to verify operation; 6) undoing the change to verify failure; 7) making the change again; 8) verifying the final change.
In other words, 120 minutes to type nine characters. Not quite as bad as fiction writers, I suppose…. But the real idea here is that doing requires thinking, and really, there’s very little difference between the two in knowledge work. Sure, if you’re hunting a grizzly bear, or plowing a field with your Fjord horses, or bolting the body to the frame on the assembly line, well in these examples there’s a big difference between thinking about it and doing it. But for symbolic analysis work, thinking is far harder and more time-consuming than doing and the two are so intertwined as to be one and the same.
July 25, 2006