I’ve always felt uneasy about the pairing of “computer” with “science”. There are two reasons. First, “science” is conventionally realized as the observation of nature; since computers are man made the rules we may derive from observation and analysis may not be applicable when we build a better or different computer. The second is that “computer science” in industry rarely seems to exhibit any of the distinguishing marks of “science”.
Perhaps you have had similar thoughts… but like so many things that flutter in and out of our heads on a daily basis never got around to digging deeper on the issue. I therefore thought I’d pass along some interesting research/discussion on the subject for your personal edification.
The first is The Cruelty of Really Teaching Computer Science (PDF) by E. W. Dijkstra written in 1988. The paper is hand-written and a joy to read. Its a bit long, but reads quickly. When reading it I found my self nodding a lot and feeling a joy that someone of such immense talent and honor has throughly given thought to these things.
The second is a piece in Wired from 2007 in which Bruce Sterling summarizes an ACM interview with Peter Denning: Computer Science. Is it Really a Science, and What’s It a Science About? in which the subject is address head on. Peter here discusses his project to produce a set of solid principles of computer science, to put these questions to bed. The results of that project are found on the site: The Great Principles of Computing project
These two resources should help you significantly along your way. There are many more, but these two stand out to me. And, because I think they are so interesting and important, I shall not do you the disservice of any further description here. 
It does, hopefully, raise in your mind a question on you can answer about yourself: “Am I an engineer or a technician?”
As I pointed to in a recent post, an Engineer is “the discipline, art and profession of acquiring and applying scientific, mathematical, economic, social, and practical knowledge to design and build structures, machines, devices, systems, materials and processes that safely realize solutions to the needs of society.”
A technician is “a worker in a field of technology who is proficient in the relevant skills and techniques, with a relatively practical understanding of the theoretical principles.” So says Wikipedia. The entry continues with a useful example: “For example, although audio technicians are not as learned in acoustics as acoustical engineers, they are more proficient in operating sound equipment, and they will likely know more about acoustics than other studio personnel such as performers.”
Dijkstra argues that we do ourselves a disservice by preferring the term “bug” (which seems somehow passive and inevitable) instead of the more accurate “error” (which is active and direct). In the same way, I think we do ourselves a disservice by blurring the lines between “engineer” and “technician”.
I must disagree with the suggestion to use “error” rather that “bug”. If programing is an inherently complex subject(which means one cannot know everything all the time) and bugs are the result of not realizing all consequences then bugs are inevitable. To make them more personal, which is the point of calling them errors, would only serve to make programmers more defensive.
We don’t want programmers to be more defensive nor do we need to. Bugs are already realized by programmers to be self inflicted mistakes.
The link for the wired article is broken. It be http://www.wired.com/beyond_the_beyond/2007/06/computer_scienc/
Link fixed. Thanks.
“To make them more personal, which is the point of calling them errors, would only serve to make programmers more defensive.
We don’t want programmers to be more defensive nor do we need to. Bugs are already realized by programmers to be self inflicted mistakes.”
Sorry, but if I wrote code and didn’t SIT DOWN and THINK IT THROUGH before I wrote it, then I wrote garbage!
Personally, I am deeply ashamed when a bug is found in my code, and it must be fixed immediately. I purposely try to break anything I write, and torture it in ways that it will never even be used in the field, in the hopes of finding, documenting, and systematically correcting all the edge cases, or sometimes even refactoring the whole concept.
And when I’m done, I turn it over to a buddy of mine who is an expert at breaking all and any code within 35 seconds or less (timed with a stopwatch). If the code passes HIS torture, then it’s deemed worthy of being checked in!
So if I screwed up, I should be called on it to correct the junk I wrote. And we really should start making all these “developers” squeal and cry when they unleash HALF-COOKED, untested GARBAGE unto the world!
If you are so sloppy as to release half-cooked garbage, and I catch you doing it, I will bust you. Because you should feel guilty for doing a half-ass job!
Bugs are inevitable. The complexity levels of software are high enough to guarantee this. Adequately educated computer scientists know this. Part of what they do is prove it with modelling, observation, and other scientific means.
One remembers that men’s life seems to be expensive, nevertheless different people need cash for various things and not every person gets enough money. So to get some home loans and car loan should be a right solution.