Well to be honest, I believe that everything I've written that's >6 months old sucks. In 6 months the stuff I write today will suck.

Oh I practice every "Right Way" metholodogy I know. I've been writing software professionally for 10+ years now, and as a hobbyist for >25 years. But I learn new ways to think about problems every day. And therefore better ways to do things constantly present themselves.

I might aliken writing code to how Picasso viewed painting. A Painting is never finished. Once it's finished it's dead - it ceases to be relevant. The same is far more true for code.

A long time ago I did Really Terrible Things. I didn't use strict, I parsed HTML 'by hand' with poorly conceived & inefficient regexes, I used arrays when hashes would do more nicely, I never used modules, I hard-coded String values directly, any many many more grievous sins. Why? Because to program & to learn are parallel pursuits. The more I learn, the better my code is.

That's the main draw perlmonks has for me. I learn by example things that I don't have time to explore personally. Sometimes this backfires, but mostly it helps.

If I look at old code I've written I usually think "what the hell was I thinking" and then I think "this would be better if I did this..." and then I remember why it got done that way in the first place and my stomach usually turns.

I'd love to say that I also always have time to do things the Right Way. But with programming salaries shrinking, industry competition growing, overseas outsourcing increasing, my managers don't always see the merit in delivering bulletproof code when simply paintball proof code will suffice in their minds.

YES, it takes longer to do things properly. If you don't realize that then you live in coder-luxury-land where deadlines are reasonable and your bosses believe in quality products instead of using endusers as beta-testers.

I've always had a habit of pursing projects in this way, especially when solving new kinds of problems:

1. Make it work
2. Make it fast
3. Make it sexy

I find it utterly mind-boggling that too many of my managers over the years don't see the benefits of going past stage 1 on the list. More often than not, they take the project away from me (usually by dumping more work on me & calling it higher priority or some other such management trick.) and then come back later with complaints, to which I must respond "If you had let me do what I reccomneded in the first place..." - which you know NO ONE ever wants to hear, since it's the analog of "I told you so"

When I've lead teams in the past I tried to be the boss I wanted to have. Maybe I pissed people off by telling them: Yes, this works great. Now go back & make it run fast. Then later, I'd say hey this works great & it's wicked fast, very nice, now go clean it up so it adheres to conventions, includes these minor feature creep items & acts better as a component in our overall system. Maybe they thought I was too demanding. But I didn't ride people, I tried to give them the room to be creative & tried very hard not to micro-manage. It's very tempting to go back & rewrite it yourself in a pinch, especially when you're the one ultimately responsible. But when you delegate properly - you learn to step back & listen more. You let people LEARN. That's what it's all about.

And that's my point. There's ALWAYS a better way to do something. If I've learned anything from the likes of Brother Merlyn and other indigeous monks of rank and reputation, then that's it.

And that's why everything I've ever written in the past sucks, and nothing is ever truly finished, until it stops being used.

- gregor42

Wait! This isn't a Parachute, this is a Backpack!