Subject: Re: becoming a better programmer From: Erik Naggum <erik@naggum.no> Date: 16 Sep 2002 07:49:08 +0000 Newsgroups: comp.lang.c++,comp.lang.lisp,comp.lang.java.programmer,comp.lang.perl.misc Message-ID: <3241151348919996@naggum.no> * otmorozok1976@yahoo.com (Scott) | Another friend tells me "define what you mean by 'better programmer'". You have received much advice, most of which I find useful given a prior understanding of what it means to be a programmer, but it occurs to me that this is far from as obvious as one might think. What kinds of things would you like the computer to do for you? What kinds of things are you already good enough at that you can teach a computer to do it? Do you have extensive experience with hardware so you want to control devices and do things like play music or movies and such? Are you adept at human-computer interaction so you want to write software that embodies your psychological insight to write software that makes a human being more efficient at some task? Have you succeeded in teaching children or adults anything and would like to write computer-aided teaching software? Do you enjoy graphic arts and typography and would like to use the computer to automate the production of, say, flyers and posters? Are you interested in photography and would like to write software for digital image processing? Is optical recognition and artificial vision on your list of interests? The list of questions obviously goes on and on, extending into every field of human endeavors. In my view, to be a programmer is to be sufficiently well versed in some non- computer-related field that you can see how the computer can aid practioners of that field accomplish their goals. Many programmers never progress beyond the point of aiding their own use of the computer and never do anything "real" -- the number of software packages that help people read mail and news and waste enormous amount of time in front of the computer are legion, but they tend to make people spend /more/ time on these tasks than they would or should have done compared to actually productive tasks. Take spam, for instance. Varying amounts of effort by an enormous number of people have been poured into getting rid of this problem, including many pretty clever filtering tricks. However, the opportunity arises for machine recognition of meaning in electronic texts such that computers can analyze and classify them according to, say, Dewey's or Universal decimal classification. If this problem was solved, such things as the Semantic Web and search engines that produced topic maps would provide vastly different perspectives on the enormous emount of web pages out there. Spam detection would fall out of this work simply by being classified in areas most people have no interest, and if you should be interested in some of the things that are advertised by this means, you would be able to locate it. Imagine a world in which you could ask your computer to retrieve news articles and web pages according to a semantic classification instead of having to try out different search words. Imagine that this classification would not need a human to classify the documents but where machines would "understand" them. What would you need to know as a programmer before you could successfully implement something like this? Clearly, being a good programmer, you would need to know many algorithms in addition to understanding the nature of classification better than most of the people who do it by hand, perhaps instead writing a system that finds patterns in what has already been classified instead of actually understanding things. Often, a the solution to a problem is very different from the solutions that come to mind immediately. High intelligence and good creativity is needed atop a vast mass of knowledge from many fields is necessary to solve the many remaining interesting problems. However, if all it means to be a programmer is to be able to code up something from a specification and a design provided by others, "all" you need is a good command of the tools you use and the language grammar and idioms to express the ideas that somebody else have dreamt up. This part of programming is not the most interesting in my view, but many people who hire programmers want them to think as little as possible and be as faithful as possible to designs made by others. To be a "better" programmer in this regard is very different from a better programmer who can solve unsolved problems. -- Erik Naggum, Oslo, Norway Act from reason, and failure makes you rethink and study harder. Act from faith, and failure makes you blame someone and push harder.