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.
In reply to Bad Code / Ugly Code
by chromatic
in thread On the Road to Perl Enlightenment, My 100th Post, and New Year's Resolutions
by coreolyn
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |