(see also LearningByDoing)
It's fine to read books and newsgroups (and WikiWiki), but reading is a poor substitute for actually doing. There are many subtleties to design that can not be explicitly put into words. It is always possible to tell the difference between a system that has been designed by someone with erudition versus a system that has been designed by someone with years in the trenches. The problem with learning from experience, however, is that you get to EatYourFailures?. (What's that old expression... if you learn from your mistakes then that must make me an expert.)
On the other hand, just because you have been through tons of failures doesn't necessarily imply that you should keep following the same course: the flip side of this is UnlearnYourExperiences?.
Of course, the best trait is to know when to apply your past experiences to your present situation, in other words, understanding the subtleties of fitting the pattern to the problem.
"An expert is someone who has made every possible mistake." Told to me by a piano teacher who was also a physics professor.
I recently worked on a contract with a small groups of developers who all had several years experience, but did not seem to have learnt from it. Sadly, the code they had written was riddled with stupid mistakes. This resulted in a system that fell over as soon as it the conditions strayed outside the very narrow set of conditions they had tested it for. In fact there appeared to have been no testing other than integration with the main application. I tried to point out the problems and was met with three kinds of responses.
Sadly, if you don't test your code, don't understand the basic requirements of a real-time system, or believe that getting something to compile is the same as testing it, there is little chance to LearnFromExperience. You have to understand what a mistake is in order to learn from it. I was very pleased it was only a short term contract.
-- Anon
See also AntiExperience, LearningMeansMakingMistakes