Cogitating Is Doing
July 25, 2006 | Life | Software
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.
Comments
I'd like to react strictly to the debugging part of this post.
Maybe those 120 minutes were the minimum possible required to solve the problem. But it might be worth spending an additional 5 minutes to try to see what clues were available and when, and if there was a way to quickly narrow the problem, and how you could have recognized that earlier. With the intent of making the next debugging session more efficient.
Sometimes a desire arises to understand everything without touching a thing, and then to make this one little elegant proof, whereas a couple of quick tests could have had you working on a simpler problem. Or led you down a long path of diversions! I think that's when pair programming can work best -- to allow one to make quick jog to test something, then have the other pull back to the main problem if the jog isn't helping.
A very academically accomplished programmer once asked me to look at a problem he had been working on all morning, and began to lead me through all the intricacies of his code. After looking at it for a few minutes, I said, "We software engineers would insert x=5; on line two." He spluttered and objected that this was meaningless and ugly and would cause an interpreter error anyway, but he finally did it just to show me. There was no change in the output. In two seconds he realized that the code he had been staring at all morning was not the same code that was running.
He subsequently quit and went back to school in computer science, deciding software engineering was not for him.
Posted by: Doug at July 31, 2006 10:31 AM
Thanks for all that. Voice of experience, and so true.
Posted by: Michael J. at July 31, 2006 10:59 PM
Post a comment
Thanks for signing in, . Now you can comment. (sign out)
(If you haven't left a comment here before, you may need to be approved by the site owner before your comment will appear. Until then, it won't appear on the entry. Thanks for waiting.)
