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.