It has been unnerving to realize that my code is actually a good programmer's worst nightmare, but my stuff has always worked and my clients satisfied, so I never worried too much about it.

One thing I've heard Larry say many times is that it's okay to speak a subset of Perl at first. The same thing probably applies to program design. I, for one, learn as I make mistakes. I learn fast because I make mistakes fast and have been fortunate enough to catch and to fix most of them.

In the EE field, engineers fresh out of college have to have their work checked by a certified engineer. It takes something like four years to earn the certification. That kind of apprenticeship/oversight would be helpful for programmers -- but the barriers to entry to programming, especially in Perl and especially web stuff, are so low that anyone motivated to spend a week learning the basics and produce something that's reasonably useful for other people.

Those of us who have a bit more experience have a professional duty to help beginners improve their skills, replacing bad habits with good. And it doesn't stop.

There'll always be someone who knows more than me, and there will be times when someone else at or near my skill level catches something stupid or ineffective or dangerous. And some problems don't have a good solution, so the best you can do is find the least-bad option.

You have to maintain a minimum level of competence (and that level is high with security issues), but if your code works and you can maintain it, don't worry too much about how it looks. You'll improve the more you write.

if your code works and you can maintain it, don't worry too much about how it looks. You'll improve the more you write.

As someone who's been really scared by some of the stuff he found today (perl coded I wrote circa 1994/5), I'll agree with this, especially if you're actively trying to improve all the time.

One thing I'd say though, is leave yourself some comments. I looked at some of my 1994 code today and couldn't work out at all what it was meant to be doing!

Aside: It's fascinating seeing how style has changed over this time too. And not just my style - perl style in general. In my perl directory were some scripts by TomC and Randal that just look so dated now. Yes, a lot of this was down to them being in Perl 4 rather than 5, but I think there's been a significant shift in what code looks like over time as well...

On the other hand, I'd like to emphasise that this approach can only work when *you* are the only maintainer of the code. Code should always be developed with future maintainers in mind. If that's guaranteed to be you, then do whatever, but if it's likely to be someone else, then an entire different set of rules come into play.

Then you're into good structure, proper comments, use (strict, warnings, taint), sensible variable names, documentation (good comments + "self documenting code" != documentation), even, dare I say it, testing!

Fortunately Perl is a great language for all of these things! And luckily it's a great language for refactoring too, so if you're stuck with maintaining really bad code, it's easy to improve it a bit at a time.

Have fun!

Tony

Like coreolyn, I am mostly self-taught. Also, I'm the only "technical" person on my development team, which means there aren't a lot of people I can bounce ideas off of. I can talk to my co-workers, of course, but they usually go into *DUMMY MODE* as soon as I start going into specifics.

First off, I'd like to thank the community at large. In the past few months, I've found a community of like minded individuals willing to share their knowledge, expertise, and (most importantly) time for nothing more than the satisfaction of knowing they've helped solve problems, improve skills, educate, and (perhaps most important) made a difference.

Thank you for making the Monastery my favorite waypoint on the Perl Way.

Certain individuals deserve more specific appreciations:

• Vroom certainly deserves the most for creating the Monastery and for being very diligent in continuing to make it a good place to hang out. Somebody buy the man a beer, please.

• Merlyn. Prolific, skilled, and knowledgeable. His personal views on honesty, ethics, and the way things should be can difficult to take at times, but he rarely (never?) prevaricates nor sugarcoats. I've heard some express a certain amount of dismay over this, but one must acknowledge the man's contributions to the Perl community and to the Monastery. Truth, like Comedy, is not always pretty nor easy.

  Also, I want to thank him for maintaining his article archives. I'm continually amazed by the amount of material and frequently humbled by the implementations. (Note that the link is to only one of his archives.)

• tilly, chromatic, jcwren, ybiC, kudra, and everyone else listed in Saints in Our Book deserve thanks for their encouragement and for their willingness to go beyond simple answers. Their willingness to share their experiences, guidance, opinions, and knowledge is inspiring and enjoyable.

  Also, Ovid deserves much praise for his CGI programming course.

  Turnstep's home node should be required reading for all new monks.

• PsychoSpunk, coreolyn, Blue, Albannach, mitd, Petruchio, alakaboo, and others have been very helpful in showing what it takes to be a monk seeking enlightenment; their other contributions are also very appreciated.

• Everyone else that I forgot to mention...

I really enjoy the fact that, despite the diversity of background, opinions, and skill sets of the active Monks, the Monastery not only helps you learn Perl, it can (if you're paying attention) help you learn what it means to be a good, professional, and ethical programmer. I've found my code in other languages improve as a direct result of the conversations and kibitzing that goes on.

As far as my challenges to myself this year:

• Complete a couple of potential FAQ's for New Monks that I've been working on.
• Clean up my home node.  Done!
• Post at least one Craft Done...posted as a CUFP.
• Post at least one Review  Done!
• Keep bugging a certain monk to start participating.
• Continue to help where I can and to improve the quality of that help.
• Lose ten pounds. (Oops; sorry. That slipped in.)

--f