Very succinctly
put:
An expert can tell a non-expert to check for such conditions, and with those specifications, the non-expert can probably code them, but only the expert anticipates them. Just like driving, what makes a good programmer is not only the ability to solve the problems that occur, but the ability to foresee (and avoid) problems that haven't occurred yet. Unfortunately, experts learn how to do that by making mistakes. It's a sad commentary on the human condition. Each generation acquires expertise primarily by repeating the mistakes of the past generations. To paraphrase Neils Bohr, "An expert is someone who has made all the possible mistakes in a very narrow field."
But when you're riding in a car with a novice driver, you'll probably appreciate P. J. Plauger's version more, "My definition of an expert in any field is a person who knows enough about what's really going on to be scared."
Comments:Unfortunately, many novice developers or ones that have just acquired a taste of a new technology immediately delude into writing something only an expert is capable. It does not matter if it is just to store data in a file as illustrated by the example
used. Or using COM, C++ framework such as ATL/STL, .Net or Java.
Many development managers lacking the experience and expertise fail to distinguish between act of stupidity and stroke of an expert, thus concur blindly allowing novice to use their
product as the training ground, often leading to failure to exploit opportunities and creating laughable products.
Often these managers confuse the expert's time and effort to "
foresee (and avoid) problems that haven't occurred yet" as being a case of gold plating and then wondering why they are having recurring problems, lack of respect and trust from their customers, and complaints.