Go reinvent some wheels. I know that sounds like heresy, but there's a hell of a lot of value in reinventing the wheel.

To back up a little, let's repeat the three cardinal virtues of programming -- laziness, impatience and hubris:

• Laziness is what makes you work like hell to automate some problem that could be solved by hand in less time -- once. The investment pays off when you have to solve the same problem a second time, though.

• Impatience is what makes you work like hell to improve code that's 'good enough if you're already used to it'. You could also call it a resolute decision not to become used to 'good enough' code.

• Hubris is what makes you look at a piece of mature code and think, "I could do it better." It's also what makes you deliver on that bet.

Now let's turn them sideways and see how they become the three deadly sins of programming -- sloppiness, rushing and arrogance:

• Sloppiness is what makes you write worse code than you could. When you cut a corner and think, "I should really do X, but what the hell, it's not that important," you're being sloppy. Laziness means doing work yourself, so other people don't have to. Sloppiness means making other people work so you don't have to.

• Rushing is what makes you start coding before you know what you're trying to do. It makes you write 500 lines of code that solve the wrong problem. It's what causes 'shotgun debugging' -- chopping out a couple lines of code here, changing a value there, and breaking things left and right because you can't be bothered to spend five minutes finding out what actually needs to be done. Impatience moves you to improve code. Rushing moves you to accept lousy code because it's here now.

• Arrogance is what makes you think you know it all. It's what makes you hypnotize yourself into thinking your pet solution is the exception to the Perl motto: There's More Than One Way To Do It. Hubris means thinking you can improve on something you know to be good. Arrogance means thinking anything you don't like is crap.

What does this have to do with programming every day? Well, what we're really talking about is exercise -- building your mental muscles and stretching your imagination so you're in top form when you need to solve a real problem.

That's Laziness.

You want to work like hell now, so you don't have to work as hard when the chips are down. With a little care, you can use that Laziness to cultivate Impatience and Hubris, too. But as with physical exercise, you'll be fighting Sloppiness, Rushing, and Arrogance every step of the way -- both in yourself and in others.

The real secret of excercise is that it's boring. The limit you really push is your ability to ignore a continuous stream of thoughts like, "I don't like this -- this sucks -- I want to stop," and keep working. That stream starts when you hit about 20% of your actual capacity, and keeps going until the endorphins kick in -- which happens in programming just as much as it happens in physical exercise.

If you learn to ignore the negative thoughts (and complaints of the people around you who don't even want to see someone working hard) long enough to feel the rush, you can be Lazy. If you let the negative thoughts stop you, you'll just end up being Sloppy.

----

So, with that sermon out of the way, the best thing you can do is go back and drill your fundamentals. Pick up a good reference on algorithms (_Introduction to Algorithms_, Cormen, Leiserson, and Rivest is very good) and build linked lists. Build circular lists. Build binary trees. Build heaps. Build hashes. Write sorting routines. Write code to implement basic data structures and algorithms, then go back and write it all again. And again. And again.

Think you know how to write a bubble-sort, Shell sort, Heapsort or quicksort? Think you can do it in one pass, without having to refer to any references? Don't think -- write them over and over until you know you can.

Then start working your way through the standard Perl library. Pick a file, and copy it -- and I don't mean <kbd>`cp /usr/lib/perl/Module_X.pm ~/My_module_X.pm`</kbd>. Transcribe it by hand, one character at a time, just so you can say you've read the thing down to the last punctuation mark.

Split out the interesting bits. Play with the techniques you discover. Find out what alternatives exist, and why the existing version is the best for any given situation. Stamp down your boredom until you understand the module well enough to implement it from scratch. Then find some Hubris and try to write something better.

That should be enough to keep you going for at least a decade or two.

Don't let people give you crap about wasting time, or doing things the hard way. You don't learn to solve hard problems by waiting for someone else to hand you packaged solutions. You learn by repeating what others have done before, and learning the sequence of thought that leads to the solution, not just the solution itself.

Walking the path is where you learn to think critically, and hone your problem-solving instincts. The fact that the problem has already been solved just keeps you from getting stuck forever in the diversions and dead ends.

If someone asks why you're "wasting time" reinventing the wheel, say, "so I can. Can you?"

Coding is not the only activity to become good. Learning the theory of good programming style also helps. That's why I heartily recommend Code Complete. Forget the fact that it's put out by Microsoft press. Just buy it.

I've learned many of my programming techniques by trial and error, or just picking up "tips and tricks" from others. "Code Complete" attempts to take best practices and lump them all together on one handbook. It doesn't mess around with project management, developing your project specification or how to sell your product. It gets down and dirty into the "this is good, this is bad" detail that every programmer needs to know. Do you want to know what cohesion is? Have you ever wondered what positive uses there are for global variables? Do your variables suffer from hybrid coupling? Buy this book and have the answers. Each section is independant from the others, so you can just focus on the areas that are most interesting to you.

Cheers,
Ovid

Join the Perlmonks Setiathome Group or just click on the the link and check out our stats.

Is there anything you can do to automate the **** out of it? I do not believe that your job is so good and so interesting that you cannot find some humdrum part that is a candidate for automating.

Anyway, once you have the task, think about how to automate it in Perl. It is a very good language for these sort of munging type tasks.

Then, once you have got some results - as I believe you will, look on CPAN and supersearch to see if there was a better way of do what you did, and how to improve your solution. Some monks argue that you should have done this in the first place, but after all you need to start somewhere.

What do you Monks suggest to a person trying to keep their skills "sharp" and improve?

Read, Write, Repeat. Read just enough to have a partial idea of how to do something, then make use of that knowledge and write a program that does something interesting/useful. If you read too much without applying what you've read, you won't find it nearly as interesting and you'll forget it far faster.

Where can I look to for inspiration, ideas or just uses for Perl?

If you looking for inspiration Where the inspiration comes from ? has lots of good suggestions. :)

If you end up with a directory with hundreds of little files, you're on the right track.

Update: I didn't say to *post* your solutions on Usenet. :)

Well at least this is something I alreadu do. CLPMisc is one rough room though! I once tried to explain how to write a clear regex but used tr/// as the example... holy cow you'd think I drowned puppies on the internet or something.
--
ellem@optonline.net
There's more than one way to do it, but only some of them actually work.

Here here! And in the spirit of this, and reinventing the wheel, try reinventing the language. Always a fun one is to implement your own hashes. Or one that was just tossed out sort, though I must admit that one would take me awhile. Also don't restrict yourself to perl wheels, reinventing functionality available in modules, is often done and you'll probably do enough of it as it is. Instead try implementing standard UN*X commands, like Perl Power Tools.

--
perl -pe "s/\b;([st])/'\1/mg"

If you want to become a better programmer, then work through SICP, even if it is not using Perl, but Scheme. If you don't want to dive into programming *that* deeply, or just want to hack more Perl, try to convert your whole work environment into a place where you don't have to do anything manually. For starters, putting together a nice logging scheme for the applications you need to watch, with automated priority-based notification mechanisms (print to some terminal, email to responsible person, pager alarm for fatal erros, etc.) might be nice.

Christian Lemburg
Brainbench MVP for Perl
http://www.brainbench.com

I second the recommendation to dive into SICP. Incredible, eye-opening text.
nop