Whenever programmers get a new toy, they play with it. They push
it to see how far it will go, and that means that they always
misuse it. This is how they learn how to use it. When programmers
first learn OOP, they overuse inheritance. When programmers first
, they try to make every method into a Strategy
and build a Facade for the smallest subsystem. When programmers
first use a system for graphically connecting components (VisualAge
is what comes to mind for me), they try to implement the whole
application using it, leading to a dense network that is impossible
to follow. In all cases, the problem is not with the technique, it
is with overusing the technique. All benefits have a cost. But the
only way to find out the limits of a technique is to go beyond them.
Ideally, we'd learn the limits of a new technique before we started
using it "for real". But that would require more training time than
we usually want to spend. So, we always end up learning on the job.
"Good judgement comes from experience. Experience comes from bad judgement."
For an interesting (although at times overblown) essay on this concept in the civil and mechanical engineering worlds, have a look at HenryPetroski?
's book ToEngineerIsHuman: The Role of Failure in Successful Design
. Much of the book resonates powerfully with the issues facing software developers. --DavidThomas
This is one of the first principles of teaching GameOfChess
or most any other skill that values accuracy. Don't be afraid to make make mistakes when learning
even if the eventual goal is perfection.
One thing to note: you do need to recognize
your mistakes in order to learn from them, otherwise you just reinforce bad habits. For most endeavors this means having an experienced coach or some other means of quality feedback. For programmers, this could be the compiler if the error messages and warnings are high quality, or one's pair when PairProgramming
or reviewing code for the more subtle stylistic and design mistakes.