This isn't the only way that I "waste" my time learning.

Learning isn't a waste of time, not in and of itself. Undisciplined learning is.

I'll try a different metaphor. Playing scales and arpeggios on the piano (or Chopin's Études) is usually a good exercise, but if you slouch or rest your wrists on your knees and have poor fingering technique, they're lousy, wasted exercises. If you let yourself slip up and hit the wrong keys, you're only hurting yourself.

In a similar way, well-focused research is often valuable. I know you make a sharp distinction (as do I) between experimental, research code and code you intend to maintain. That's a very important point. If discipline in practice and research is important (and it is), it's because it helps to establish and maintain good habits for when you use your skills for real.

chromatic,
Learning isn't a waste of time, not in and of itself.

I only meant waste in the sense of throw away code with no immediate tangible benefit and not in the sense that there was no value. Putting quotes around it didn't do an adequate job so I will draw on another analogy.

A friend of mine who is an artist in the traditional sense (painter) told me that his really good stuff only comes when he is inspired by the muse. This was after telling him I was spending less and less time playing around with math. He told me that it was important to practice your craft every single day so that when the muse hits you, you don't waste it relearning the basics. He went on to say, it isn't even adequate to practice the same techniques - you needed to take this "down time" to acquire new ones.

I think of my time that way. Preparing for when the muse hits me or when the need to be practical forces the issue. I don't know when, if ever, this knowledge will come in handy but I spend my "down time" learning it just in case. In a number of instances, I have learned a lot more by "breaking the rules" than by following them. I understand well that my philosophy doesn't apply to most people or even to myself in all situations.

I try not to speak in absolutes such as "Never do X". Unfortunately - applying common sense and critical thinking is not universal. Otherwise, we could just say "Never do X unless there is a good reason". I just saw a good opportunity to expand and enhance:

If you're only playing around and throw away the code after you've finished, that's fine -- but ignoring all of the knowledge available about what works, what doesn't, and which ideas seemed good but turned out to have problems means you're shortchanging yourself (and anyone who relies on the code) out of false hubris and false laziness.

Cheers - L~R

I read an article some time ago (I don't remember where), about a class for rock climbing where they used exactly the opposite approach. They would start new climbers off trying to climb a relatively simple wall.

After the students had a little time falling and struggling, the instructors would go back and explain the basics to a group who were much more focused on learning not to make the mistakes they had just experienced.

I think we can all agree that random practice without comparison against a standard or correction by a more experienced mentor won't be very effective.

On the other hand, the only way to learn how to attack a problem from scratch is to do just that. It sounds like the OP has a strategy that makes sense for his learning style. It also happens to be one that has served me well in my career.

You are making a distinction between research and production code. I thought the OP made it clear he was talking about the former.

G. Wade