In almost every subject we may study there are efficient and inefficient ways to go about learning it. It seems foolish to go about learning in a hard way, if we know of an easier, better one.
Beginning somewhere back in the later 1800's, even the best schools for telegraphers started teaching the new student the Morse code by giving him a printed chart code to "memorize" visually. The implications were that learning the code is going to be hard and will take a long time to master. So the student expected it: that's why, if he could afford it, he went to a telegraph school. Without realizing it, he was thoroughly prepared to begin in the worst possible frame of mind and way.
This attitude carried over naturally into the early days of amateur radio and continued for a long time afterwards. The whole atmosphere was "it's hard". Isn't that still the attitude of most people today? We need to get rid of the idea that it is hard -- it isn't. Experience has shown that the best teachers have avoided that idea completely. Learning the code, as well as using it, ought to be an enjoyable experience, easy and even "fun". Such teachers also ignore a student's errors in order to avoid negative reinforcement.
The old way of learning by a visual memory or by counting dits and dahs analytically is almost guaranteed to produce that old and famous "plateau" at the fastest speed the mind can handle such a burden at a conscious level --usually around 7 - 10 wpm. Those who take each code character and put it through such a mental routine to get the letter for which it stands are on their way for trouble -- they soon get stuck on a plateau.. Why should anyone bother to make the conscious mind go through that sort of thing at all, since it is so futile and is really working against us? The only obvious reason is that they don't know any better.
An analysis of that old way of learning is like this: The student
As late as 1975 George Hart in the August QST (p. 100) wrote "Most code learners start out by memorizing the alphabet in terms of "dots" and "dashes" or "dits" and "dahs". Even those who are cautioned by an enlightened instructor that A, for example, is not a dot followed by a dash. but a sound whose closest voice emulation is "didah" -- even those usually "memorize" that it is a short sound followed by a long sound. . . . Thus, the initial stage of code learning with most people is a counting procedure, and no amount of emphasis on sound is going to change this." How discouraging and unnecessary! He pointed out that the way to learn the code is by first hearing the characters it at a speed too fast to count and learning them as rhythmic units of sound -- sound patterns. This is the way the ARRL code teaching programs now do it.
Many, many people have managed to master the code by methods which we cannot recommend today, but they have done so at a heavy cost in time and effort, and often have experienced great discouragement along the way. They have managed by persistence to overcome the stumbling blocks and achieve success in spite of them. But countless others have gotten stuck and given up at some slow speed, generally less than 10 - 12 wpm.
Through the years all sorts of schemes have been devised for "memorizing" the code, and some of them quite ingenious. Most of them involve some kind of visualization: a pictorial or a systematic arrangement of printed coded characters, based on their structure, a "chain" of relationships of some sort, adding to or exchanging components of one character to obtain another. A few have devised words or phrases presumed to have a sort of "sound-alikeness" to the code character. Such methods probably would help a person who might sometime need to signal for help in a dire emergency, but they are worse than useless, of no value at all for regular telegraphic communication.
There is never any reason to see the code in written form. Never translate "dit plus dah means A" and then write it, or as another has said: "If you find yourself hearing 'dahdidahdit' and saying to yourself 'Aha, that's a 'C', and then writing it down, you're in trouble -- that's translating."
Most of these well-intentioned aids to learning have overlooked the fact that the code letters are an alphabet of SOUND. Their "aids" have interposed something else between the letter-sound and the letter. Most of these methods present their schemes to the eye, not the ear. Even those which purport to use sound (such as "sound-alikes") fail to provide the necessary unity of sound pattern (partly because they are too slow, but also because the "sound-alikes" are extraneous and distracting). Both kinds require one or more extra steps -- translation steps -- to get there. Those which require some sort of analysis (such as how many dits and dahs) of each character in order to identify it, or which run through a series of some sort, also have introduced needless steps which inevitably slow the learner down, and usually severely limit his achieving speeds over about five to ten wpm. Avoid them.
Very many of those who originally learned the code from a printed chart of dots and dashes began the bad habit of counting the number of dots and of dashes from a mental chart. Then they must decipher the longer characters by counting: for example, to separate B from 6 and 1 from J. Some of these hams were able by much practice, and perhaps realizing the nature of the problem, to overcome their speed plateau. (I knew one experienced ham-ex-navy-commercial operator who could go right along at 20 wpm this way, but that was his ultimate limit. He loved the code, but could never advance a step further. That was as fast as he could analyze -- pretty fast at that!).
Those who have learned by the "sound-alike" methods, (e.g., they hear "didah", and it sounds like "alike", which they have been taught means "A") rarely reach even a ten wpm plateau.
One method extensively advertised for many years "taught" the beginner by the scheme "Eat Another Raw Lemon," which was supposed to remind him how each of the four letters E A R L was formed, each one adding one element to the previous one. This was illustrated by large printed dots and dashes. There must have been a good many who started out this way, and in spite of it, at least some of them finally managed to become proficient. I knew of one such amateur who got to around 20 wpm that way.
The expert teachers tell us that any kind of printed dots and dashes or any other such pictorial impressions will only impede the student's progress when he is beginning to learn the code. Chapter 13 explains why.
All such methods violate good pedagogy, because they do not teach the code the way it will be used, as actual sound patterns. They also require the student to learn something (which he must later forget in order to advance) in addition to the sound of the code itself. While these methods may seem to make it easier at first, they actually make it much harder, or even impossible, to advance. The wise teacher and student will avoid these approaches.
When a old timer, who had "learned" the code as it used to be taught from a printed chart, suddenly recognized that the sound pattern is the letter, it was like a light bulb flashing on. After that he began to progress rapidly.
Arnold Klein N6GAP said: "For more years that I care to admit to myself, I have been trying to master a simple task: copy code at 20 wpm for the Extra class ticket."
He practised so much that there was no extended period of free time when he wasn't thinking code. He wore out a cassette player listening to tapes while driving, cutting the grass, sweeping, planting flowers, walking during lunch, using the tread mill at night and while washing the dinner dishes, while watching soft ball games he had the earphones on and copied in his head. He copied code while waiting in the doctor's office, while parked as his wife went shopping in the evening he copied CW on the rig -- a grey haired man wearing earphones and writing on a clipboard!
"The results were frustrating. The speeds ranged from 20 to 24 wpm and always there was that sense of panic, that I can't keep up" -- "tailgating" - that was exactly what he was experiencing. The problem was he didn't know what he was doing wrong. Asking those who passed the test resulted in the casual answer: practice. "Well, my practice just wasn't doing it". Magazine articles on copying behind did not relate how to learn the technique. The stock phrase seemed to be that the ability to copy behind will magically appear after enough practice.
He wrote like this after reading the principles presented here: "Mastering the code has taken on a life of its own and I am determined to do it. . . . I have now tried these during the week since getting them and they do work! I am losing the pressure to keep up. Keep calm is my newest admonition. They have given me the answer to the problem I've carried for years."
The methods presented in this book are time-tested practical, working methods.