(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.

	* A failure to understand what the problem was. example - "what is wrong with sending text strings to a polled serial transmit routine from within a serial character interrupt?"
	* That could never happen - "[in practice] it only ever gets one message at a time", for a system connected to a network.
	* "It has worked fine for 2 years" - because we've never tested it properly, so didn't find the stupid mistakes. Or didn't associate the random crashes with a potential problem in the software!

No had noticed that the static storage was not being initialised to zero on boot. No-one noticed that the OS had a bug which caused task's stack frames to move on task switches, resulting in auotmatic pointers becoming invalid! Some code was declared 'tested', when it needed to talk to a bit of the hardware that hadn't even been designed yet. Even when I told them these things they did not understand the significance.

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
----
CategoryEducation