|Perl: the Markov chain saw|
(Ovid - on the shoulders of giants)by Ovid (Cardinal)
|on Dec 14, 2000 at 22:29 UTC||Need Help??|
Thanks for some great comments regarding that article. I liked your points and think I have not changed, but "shifted", my mind a little bit.
Maybe the software is nice, but many programmers still suck. Much of what he have today is built upon past knowledge. That's a good thing because experience counts. But really, despite the crud that Matt Wright spews out, his code is often better than much of the "production" code out there. Some of the dreck that I've had to work on is a crying shame. What's a crying shame isn't necessarily that it's so bad, but that it's so easy for me to spot the flaws. I am NOT a programming guru. I work hard to learn more and to find newer and better ways of doing things, but I have a long way to go.
Would you agree with me if I said "programmers still suck?" Much of what you mention above is based upon past successes. The people who worked with these ideas were brilliant pioneers and certainly we have some today. But I am still concerned about the mass of uneducated programmers that we have today. They ride the "gravy train" provided for them by companies desperate to have anyone who can "do the job" -- whatever that means.
An interesting idea was raised in the previous thread on this topic: licensed programmers. A few months ago, some friends and I were discussing trying to formulate a group, or "guild", for independant certification of computer professionals1. It initially grew out of an idea where geeks would for an association to defend "ethical" principals. Programmers wouldn't work for companies that pull stunts like etoys, for example. There was enough disagreement regarding "ethical" that somehow the idea evolved into "guild" concept.
The guild was a fairly straightforward idea: having and MCSE or RHCE is nice for the boss, but can you really do the work? I know people who have CS degrees who can't code worth a darn (one actually argued with me that liberal use of "goto" is a good thing). Sigh. Our frustration stemmed from the fact that programmers who build upon past successes aren't suddenly good programmers. Sure, I can build a a dynamic Web site and toss on search engines and a nifty database back end. If you threw me back 5 years ago, much of what I do would cause a lot of oohs and ahhs. Today, it's recognized that I am standing on the shoulders of giants. In no way does this make my code better unless I am willing and able to take the time to learn why the "giants" wrote such nifty code.
This has unintended consequences which causes modern software to have new problems. Ten years ago, did most people sit around and worry about their credit card being stolen online? Fifteen years ago, we worried about whether we should buy and IBM, Apple, or Atari because we wondered who would win. But by and large, whenever I worked on those systems, I didn't find my machine crashing every twenty minutes with a blue screen of futility2. Software apps were small (well, with 64K of memory, they had to be) and were focused on the task at hand. Why the hell does my word processor have an embedded photo editor? More features does not mean better software.
To rehash my point: standing on the shoulders of giants does not make me a giant. Software is bigger and more glamorous, but I think that companies are in such a mad rush to hire people that they just don't care/know if what they are putting out is any good. I acknowledge that the overall level of code quality is better: less "spaghetti" code, greater modularization, etc, but it's a slow and painful process. Our profession would be better if we found some way to address this.
1. I suggested the name of our site be lysistrata.org, but I got a lot of blank stares. :(
Join the Perlmonks Setiathome Group or just click on the the link and check out our stats.