Over the years CS has solved many problems. Many, many problems.

Yet everyone insists on solving them afresh. Often not even knowing they've been solved. Sometimes, when previous solutions are pointed at, they claim "I was doing it to learn". This begs the question: to learn what?

To learn how to write a module? Well, that's fairly basic, and the ancestor node of this post failed if that was their intention. No POD, no tests, ergo useless. Perhaps it's an attempt to implement an algorithm. Again, with no tests, how do you know it's working? Aside from a lack of tests, what is new about it? How does it differ from the other implementations around? Was any research done as to what would be a good way to implement it or was it from the top of one's head?

The world is full of documented algorithms and approaches. It's full of libraries that implement all sorts of things. If you ignore CS, you are doomed to reinvent it, and often badly. And not only that, just think what you could be doing instead. You're effectively dragging down the community when you could be contributing to something and making things better.

A splendid example is the CGI.pm module. It parses query strings correctly. Now, we've all seen hand rolled query string parsers, and they rarely get it all right. How many of them understand the ';' notation that one can use instead of '&'? How many of them have problems if a key is specified multiple times? People looked at their browsers and saw what they passed their programs. They looked at their programs and saw what they were given. They probably assumed this was the complete range. Did they consult any RFCs? Did they check the CGI.pm source? Did they look in the source for any CGI libraries for other languages? Probably not. Did they have a good reason to not use CGI.pm? Probably not. Is their version inferior? Definitely.

People forget that CPAN is a vast resource for learning. There's a lot of good code out there. There's also a lot of bad code. It's amazing the value of studying bad code and going "Even I could write that better" and then doing so. Looking at the good code is also good. You can see what they're doing, or try to work out what they're doing and why.

If you don't do research, how can the art be expected to progress? Are we fated to forever be writing btree and hash implementations from scratch without reference? Or worse, stuck with lots of programs using straight indexed arrays rather than a more efficient structure for no good reason other than not knowing any?

At a university, you'll study the common data structure and algorithms. Even more amazingly, you aren't expected to just come up with them. You're expected to research. Or maybe your lecturer will just give them to you. In later years, you'll be asked to do things like implement red black trees (for example) and you'll certainly be expected to research. Maybe you'll come across other interesting and useful algorithms while you're researching. At the very least, you'll learn how to research if you haven't already.

Read magazines regularly. Read perl.com articles. Subscribe to tpj.com. Subscribe to safari.oreilly.com and rent books you'd never pay cover price for. Read journals of societies such as ACM and IEEE. Any decent university library should have an archive of the older issues and these are often just as relevant as the newer ones. Further your art.

It all comes down to one of the truly important aspects of being a programmer: being able to think. In order to think well, you need input. Do research. You'll learn more.