3.3 Observation
One of the most important skills you can hone as a developer is the power of observation. The biggest lesson to learn is how not to make things up. One way to learn this is to spend a stint answering calls on a help desk. Because so many of the people who call give such blatantly incomplete, inaccurate, or imaginary information, you will quickly realize the proper ways to describe a problem.
Why is this important to you as a developer? It's about better communication, and better understanding. Better communication because when you're working with someone else, you have to convey your ideas and experiences to them in the slow, limited medium of speech rather than in the lightning fast way in which richly expressive thoughts zip around in your head. Until development teams can use mind melds to communicate, you have to make the best of the bandwidth bottleneck called your tongue. Better understanding because whenever you articulate something inaccurately, even if you're the only one listening, part of you will take it at face value and then get confused.
How does this "making things up" show up? Let's say someone is running a program containing the following code for sending a report back to them:
open MAIL, "|$SENDMAIL $address" and print MAIL "Subject: Report for ". localtime, "\n\n" and print MAIL ´/usr/local/bin/dbquery $month $day´ and close MAIL or die "Unable to send to $address: $!\n";
But on execution they receive an empty e-mail message. On further inspection, they see the program (let's call it frozzle) had printed:
Can't exec "/usr/local/bin/dbquery": Permission denied at ...
At this point, they contact their system administrator and say, "Hey, the frozzle program doesn't have permission to deliver mail to me."
What happens? The sysadmin goes off on a wild goose chase for misset mailbox permissions, wrong firewall settings, or broken sendmail rules.
Well, usually not. Any sysadmin worth his or her salt will not take this problem report at face value but instead will ask these three questions:
What did you do?
How did the computer react?
What were you expecting it to do instead?
And the answers to these questions require absolutely no computer knowledge, intelligence, or guesswork whatsoever, just observation:
I ran the frozzle program.
It printed Can't exec "/usr/local/bin/dbquery" . . . and I received a blank e-mail message.
Usually it prints nothing, and I get a report in my e-mail.
However, today it is common for administrative layers to interpose themselves between the user and their system administrator. If the user has to call a help desk that transcribes their problem report into a trouble ticket database, then assigns a sysadmin from a pool to work on the problem, the chances are much higher the sysadmin will end up on a wild goose chase (particularly since the help desk probably assigned the ticket to the mail server group).
When you're dealing with customers, you'll train them to describe their problems in terms of answering the three questions. But even as a developer, you need to be adept at doing so yourself. When something goes wrong, know the difference between what happened and your guesses at what it means. As developers, we've often gone on goose chases much wilder than the one described earlier, all because we got some bee in our bonnet about what we thought was really happening.