Ummm, interesting topic... Everyone has unique programming experience. I will include mine here as well.

When I first started using Perl, I already had years of experience with Basic, Pascal, C and Assembly.

I taught myself programming trough trial and error, and sheer quriosity. So before I went to Uni in 91, I have already experienced a lot of good and bad programming, so I know the benifit of having a clean coding style. The skills I aquired through hacking got formalized at Uni, where I learnt that most of the solutions I came up with during hacking were already invented by greats even earlier. I sat down and began reading books on programming.

I was introduced to the great language of LISP (for the "real" programmers :-D ) at 1st year Uni, where I quickly aquired the skills of toying with algorithms, such as solving symbolic equations progmatically with recursion and parsing.

I picked up Perl as a small part of my first job after graduation, where I mainly used C on the Solaris system. I was reluctant at first with Perl for its speed, but then gradually replaced all my shell/awk/hack with Perl for its simplicity and elegance.

I can think of a lot of "bad" programs I wrote in Perl in early days, here is one of them -

# Mundane C style "for" loop
for ($i = 0; $i < 100; $i++)
{
   print "$i\n";
}
[download]

Then I found out I can do this -

# Perl style "for" loop
print "$_\n" for 0..99;

# or this
map { print "$_\n" } 0..99;
[download]

Recently, doing a Schwartzian Transform on a huge hash table that thrashed the machine.

And my worst ever experience in Computer Science -

When I entered Uni, I wasn't a big fan on algorithm, I "thought" I knew how to program. Once during a class back in Uni, the professor was just about to start on the Heap Sort algorithm, having finished on sequencial sort. I quietly made a comment that if I wanted to make sorting go faster, all I have to do was to rewrite the sequencial sort in assembly.

Somehow my professor heard what I said, and that was it. He was so furious with me, and spent the next half an hour "educating" me, explaining to me that having a good algorithm is far more efficient than coding a bad algorithm in assembly. He was drawing comparison graphs on the board between C version of sequencial sort, assembly version of sequencial sort, heap sort and quick sort... I learnt my lesson.

The conclusion: what makes a good program tick is not about what programming language it is written in, not about the coding style, not about how much comment in the code (even though it is very important), it's all about the algorithm. A good algorithm alone does not make a good program, but a good program can not be without a good algorithm. A great algorithm combined with clean coding makes a great program. Always look for ways to enhance algorithm and make it run better and faster.