Decades ago, when I was first learning programming, there were only a few interactive terminal systems on campus. You had batch programming with cards, usually. Now, it wasn't like the real old-timers - there were departemental staffers on hand to drop your card deck into the reader right when you showed up, but you often had to wait hours for your job to reach the front of the queue and your output to print. So it was costly to run a program with errors. The result of this was that I would spend a significant amount of time looking over my program for syntax errors, logic errors, etc. I had plenty of time to retype a card, but only so many read, queue, process, print runs I could fit into the day.
These days, its easy to compile and run. Heck, with interpreted languages, you don't even compile. And this seduces me into the problem this post talks about - One More Try. Now, this is different from a debugging session, because it might not be my code, and I might be looking for an issue in a library. But if I am writing new code, and I run it, find it fails, I'm way too easily lured into the rapid tweak/build/run cycle, and that leads to long nights, because I don't stop to see what's really happening. Sometimes I can't see it, but if I stop, look at the code, and decide where things might be going wrong, I can at least put log messages or other debug at the right places.
The Ninja Lesson - seek to understand the essence before you act to change it.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
No comments:
Post a Comment