58KB
The Psychology of Computer Programming — Chapter-10: Motivation, Training, and Experience
- Source: /library/The Psychology of Computer Programming/source-file.pdf
- PDF pages: 234–256
- Pages without text: none
- Note: Includes the Silver Anniversary comments that immediately follow the original chapter. Text comes from the scan's OCR layer and may contain recognition errors.
MOTIVATION, TRAINING, AND EXPERIENCE I sychologists know that human performance on a given task is a function of the task itself and as understood by the subject. They also know that performance will be influenced by _indi- vidual differences in such areas as personality and intelligence. But even though personality can be changed, and intelligence can be raised somewhat, real improvement in performance has to come from training and experience. However, psychology is not an exact science, nor can it ever be. Once the psychologist takes into account the task and the subject’s under- Standing of the task, once he has taken into account all measurable in- dividual differences, and once he has taken into account all the training and experience, he is still left with a residue of unexplained performance. For example, the same individual doing essentially the same task a day later may do a worse job than he had done previously. Since his intelli- 180
Motivation, Training, and Experience 181 gence and personality are presumed not to have changed in one day, and since his understanding of and experience with the task should only have improved, how can such a decrease be explained? This residue, after all the other factors are taken into account, is called “motivation.” Volumes have been written on the subject, even though there is still doubt in psychologists’ minds whether or not such a thing really exists. We have already spoken about some aspects of motivation as they are seen through variations in group or team performance, and in a certain sense we would be better off not opening this Pandora’s box again, since we can hardly give it adequate treatment here. But we must say something about motivation before we can say anything useful about education and training, for two reasons. In the first place, if there is a residue of performance attributable to motivation, then this residue is inaccessible to training and education and sets limits on how much we can hope to accomplish by these means. Secondly, the residue might be all there is to education and training. It could very well be that if some- one is not motivated, there is no easy way to make him learn, and if some- one is motivated, there may be no way to stop him from learning. MOTIVATION Probably the best illustration of what motivation is came to me when | was reading the following passage from the beginning of the section on Motivation from a standard psychology text: Even the most cursory examination of the behavior of man leads one to the assertion that man is not a passive victim of circumstances. Instead, we all easily assert that man seems to decide which stimuli to react to, which to ignore, and which information to learn, which to neglect. These observations form the basis for ascribing to man some sort of an inner ‘‘directing drive” or ‘inner spring.” This inner directing force is what most of us mean by “motivation.” (Krech, Krutchfield, and Livson, 1969) ~Now the interesting lesson in this passage arose from the fact that this was not a new book, but had been bought used from the college bookstore. The previous owner of the book had, in this passage, meticu- lously circled in orange pencil certain letters in various words. Evidently, it was a form of doodling, either when he was supposed to be studying or when he was supposed to be listening to the lecture. When the letters were read off in sequence, they spelled S-A-L-L-Y-S-A-L-L-Y What better illustration could we give of the “inner directing force” which “most of us mean by motivation.”
182 Programming as an Individual Activity It is certainly unnecessary to point out that programmers, too, may be, at times, wondering what became of Sally when their managers would rather they were wondering what was wrong with some tally. One error that managers make, however, is to assume that a lack of performance means a lack of motivation. Consequently, they may attempt to supple- ment the lack of “inner driving force” with a little “outer driving force,” just when the programmer is suffering from too much, rather than from too little. One of the best known and accepted results of motivation research is that increasing ‘‘driving force’ will first increase performance to a maximum, beyond which addition of further driving forces will quickly drive performance to zero. The rapid fall-off in performance is especially observable in complex tasks, which is why it is so important for pro- gramming. Trying too hard, say, to find a bug, is as bad, or worse, than not trying at all, and many bugs have been exterminated only after the programmer had given up and stopped pressing. Pressing a programmer for rapid elimination of a bug may turn out to be the worst possible strategy—but it is by far the most common. From the point of view of a programming manager, or of the pro- grammer himself, the first important question about motivation, then, is how motivated is the programmer already. The answer to this question tells whether to look for ways to increase or to decrease the driving force. Overall, it has been my experience that programmers as a group are overmotivated, which is a major reason why so many programming projects fall apart as the pressure grows. But once we have established whether force has to be added or sub- tracted, what can we do about it? The problem facing an individual is probably insoluble, for how can he change his inner driving force unless he is motivated to do so? Actually, though, he has available the same kinds of strategies that a manager has—he must change something in his external environment in order to have a chance of changing something inside. Of course, a particular external change will not produce the same internal change in each group of people. Parading a naked lady by the door will certainly affect men differently from women. And individual men or women will be differentially affected—as the Candid Camera movie, “What Do You Say to a Naked Lady?” showed so vividly. But perhaps programmers as a group have some commonalities in their reactions to external stimuli, just as men, no matter how different, generally share some reaction to a naked lady—the reaction of interest, at least. We have made some preliminary studies to try for some insight into what external factors motivate programmers. We did not run experiments, in which we would have had to subject programmers to different stimuli
Motivation, Training, and Experience 183 and then observed their work patterns. Instead, we surveyed programmers and their managers about what they thought motivated programmers. We emphasize the word “thought’”’ because there is no necessary relationship between what a person says he does or will or would do and what he actually does. With that reservation, we can report some of the more interesting findings. Among software programmers at one large shop, we found that “a Salary increase and/or bonus” would “make a large effect on the results my manager would see in getting me to work at a sustained fast pace or keeping me diligently at work.” A very close second, as we already expected from social psychology, was “personal involvement in planning of our task.” Then, tied for third place were the two items—‘“a promotion’”’ and “more time to give my work a personal touch of quality.” These four topped the list of nineteen choices. At the very bottom of the list was “lessening the scope of my work,” which is reasonable in that it seems to jibe with the favoring of more involvement in overall planning. Just above this choice were four other low-favored choices. The first was ‘‘assistance in documentation, copying, etc.” which seems to contradict the folk-wisdom about the universal distaste for documentation work. But such a conclusion may be premature—it could be that these people had already reached a state where they were not doing docu- mentation anyway and that factor wasn’t important. Next of the four was “placement in a prestige position,’ which seems to contradict “promo- tion.” Further investigation revealed that ‘promotion’ was essentially associated with “more money,” rather than the acquisition of a new title—which goes to show the difficulty of taking opinion surveys. The last two of the four seemed to be contradictory: ‘relaxation of target dates” and ‘tightening of target dates.” The contradiction is re- solved if we observe that it is consistent with the view that target dates are not very important to this group at this time. At this time—an im- portant qualifier. At the time of the survey, the project deadline was not within six months. We would have liked to check again in several months and see if ‘‘target dates” were still at the bottom of the list. Which brings us to another major difficulty with motivation studies. Even if these responses truly reflect differential strengths of outside forces, they represent those strengths in a particular circumstance at a particular time. Toward the end of a project, people are motivated differ- ently than at the beginning when the goal-setting is at hand and the target date is far off the horizon. Early in a career, one is motivated differently than later on—money, for example, may grow less important as savings grow, salary grows, and debts to oneself are progressively paid off, Or, in certain circumstances that we have seen, additional money can actually drive a man off the job.
184 Programming as an Individual Activity It would be tempting at this point to say that the money motivation is not as real as the concern with participation in goal setting and quality of the work, but there is no real justification for believing that pro- grammers as a group are any less concerned with money than any other group at a comparable pay scale. Of course, programmers tend to be on a rather high scale compared with the general populace, so we might expect that money would be less motivating for them. And it may be, but we haven’t proved it by our studies. Then again, money is an ambiguous motivator. Some people it motivates as a means of obtaining what they want or need, some it motivates as a symbol of the value that is placed on their work. But what difference does that make; money is money, isn’t it? Not precisely, for if the money is valued more as a symbol, then programmers could be motivated with other rewards than money— such as extra time to give work a personal touch, or a piece of the planning responsibility. Not just to save the company money, mind you, but to motivate them more effectively, for an increase in salary only motivates for a short time—it is the raise, not the salary level which is a symbol of current value. A continuing series of raises is probably out of the question over any long interval, but continuing participation and continuing time for quality work are not out of the question at all. Anyone who has ever seen a programmer at work—any wife or husband of a programmer who has ever tried to interrupt a terminal session or a conference over a bug—knows that programming itself, if the programmer is given a chance to do it his way, is the biggest motivation in program- ming. There is an old saying about chess that goes like this: ‘‘Chess, like women and music, has the power to make men happy.” | think we could safely say that “programming, like chess, women, and music, has the power to make men happy.”’ Someday, | suppose, | will pick up a used copy of this book and find that somebody has circled various letters to form F-O-R-T-R-A-N-F-O-R-T-R-A-N. TRAINING, SCHOOLING, AND EDUCATION Certain people claim that they can take any person who walks in the door and train him to be a competent programmer. Although this is a slightly biased view—because not just anyone walks in the door of a computing center looking for a job—there is at least a grain of truth in it. Once, on a visit to a highly successful software firm, we had the op- portunity to spend the afternoon with their systems programming team.
Motivation, Training, and Experience 185 The five members of the team had the following backgrounds to qualify them for their positions of high responsibility:
- A man of 33 who had been thrown out of an Ivy League school in his sophomore year because all he wanted to do was play bridge.
- A woman of 28 who had majored in Spanish literature at a private girls’ college in the South, then went on a binge from which she emerged three years later in a narcotics recovery program where she learned programming.
- A former computer maintenance engineer, also 28, whose only formal education past grade school was at a Navy electronics school.
- A 55-year-old mother of five grown children who had taken a Teachers’ College degree thirty-three years ago, but had gotten mar- ried and never taught—and who decided to take up programming to occupy her time when her children had gone away.
- A 30-year-old man had gone straight through college (with honors) to the M.A. in mathematics, whereupon he entered the programming business. He was considered the odd-ball of the group. Although the heterogeneity of this group might seem to argue against training for computer programming, it is actually only an argument against the “normal” educational process as a training ground. What the members of this group had in common was four years of working together under one man—one of the founders of the software firm—who devoted that time to shaping them in his own image. Such a situation is not as unusual as it may sound. Most people who have been around the programming scene for a while can describe similar groups they have encountered. The striking factor is always the Same—several years of working together on real projects under a formidable leader. But those years represent training and experience— not, perhaps, the common or conventional kind, but all the same holding promise of what we might achieve could we but extract the essence of the process. One of the confusions standing in the way of educational progress is the confusion between schooling and education. Another is the con- fusion between education and training. To illustrate these confusions and how they impede progress, | would like to present some results con- cerning the effectiveness of my own teaching. In the course of several years of trying to teach operating concepts, | found that without machine experience with operating systems, the concepts seemed to have no force. That is, | would visit my students on the job a year or so after they left school and find that they were not applying what they had “‘learned’”’ in my classroom. Since | attributed this loss of learning to lack of practical experience,
186 Programming as an Individual Activity | decided to change the course into a workshop in OS/360. But in the workshop mode, | discovered that the students were having a terrible time seeing the concepts for the details. In particular, the details of the Job Control Language seemed to be standing in their way—an observation that corresponded well with reports coming in from the field. In more particular, the handling of ‘‘nonsignificant’” blanks and continuation cards seemed to be the source of enormous trouble—if the amount of griping was any measure. | therefore decided to emphasize these petty syntactic details in the lectures and to keep records of the student performance through some class problems. The problems involved creating, punching, and testing a series of job control cards through successively more difficult exer- cises. The results were rather discouraging, as shown under “Class #1” in Figure 10-1. Eighty-three percent of all JCL errors were ‘‘blanks’’ errors—that is, the types of errors | had specifically emphasized in class. | then decided to compare this behavior with another class using the same exercises—but without spending any class time on the subject of “blanks” errors except to answer specific questions. The behavior of that class is shown as “Class #2” in Figure 10-1. It appears from this chart that the net effect of my arduous attempt to teach JCL syntax by lecturing was a reduction of relative error rate from 87 to 83 percent. This is assuredly not a statistically significant result. It is a significant result, however, for the psychology of programmer education, for it shows that schooling—or lecturing, in this case—need have little or nothing to do with education. It may be, of course, that some other Figure 10-1 Errors by JCL beginners.
Motivation, Training, and Experience 187 instructor could have had an influence on this behavior—I don’t claim to be the world’s finest lecturer. But then, | can say in all modesty that | am not the world’s worst, either, so a good many other lecturers would have had this problem getting across their ‘material.’ Now, why is it so important to get across such trivial material, any- way? Unfortunately, although the intellectual content of the material is not great, failure to learn it absolutely impedes further progress in learning to use the operating system. Which brings us to our second distinction—education versus training. Roughly speaking, by ‘‘education”’ we mean acquisition of general principles and skills, and by “training” we mean acquisition of specific skills. Thus, we speak of “driver training,” “military training,” “adult education,” and “liberal education.” Not that the words necessarily tell what is going on in the school. Military training certainly teaches general principles that affect one’s point of view for a lifetime, and adult education is more often than not merely training in some specific skill. But more important, education may be impossible without certain training as a prerequisite. In our case, experience on the computer was necessary to impart operating systems concepts in a lasting way, and ability to manipulate JCL syntax was necessary to get operating system experience. Thus, failure to train in JCL syntax led to failure to educate in operating systems principles. Perhaps we should say “failure to school in JCL syntax” led to failure to educate, because eventually Class #2 did become trained in JCL syntax, as shown in Figure 10-2. By the end of ten exercises, 13 of the 17 students had mastered the skill of creating JCL cards without “blanks” errors (although two of them regressed slightly on problem #11, which was a bit larger than the others). The other four students did not show any marked increase in this skill, however, and this failure was still standing in the way of their progress in operating systems concepts. No doubt they would have learned the skill eventually, but the class terminated at that point and they were sent back to their home locations. Quite likely, they remained aloof from the operating system, whereas the other 13 could now approach it with confidence for further learning. In summary, then, the difficulty of acquiring skill—training—in JCL syntax creates a barrier that blocks further progress in operating system education (and incidentally creates an elite group of JCL “experts” upon whom other programmers remain slavishly dependent). This barrier cannot be removed by lecturing about it, but it can be removed by putting the learner in a situation where the machine keeps giving him the experience he needs. No doubt a system could be created which would do this job more efficiently and effectively than OS/360 itself—an on-line terminal with JCL syntax-checking facilities, for example. But bad
188 Programming as an Individual Activity Figure 10-2 Errors by JCL beginners with training. as OS/360 is, it is a kind of teaching machine if we can but get the students to use it. This is the service the “school” can provide in this situation—encouraging the student to keep trying in face of OS/360, or as one student termed it, “Obstacle System/360.” FORCES AGAINST LEARNING To a surprising degree, the only time we fail to learn is when there are negative forces set up against it. We say ‘surprising’ because so much emphasis in teaching is placed on motivating people to learn by using all sorts of clever devices or tricks. If we could observe children learning, however, we would see that any child really left to his own devices will learn vast numbers of things—not necessarily the things we want him to learn, but vast numbers all the same. In order to try to shape his learning into the form of the things we want him to learn, we build certain walls and open certain doors. When he learns, we con-
Motivation, Training, and Experience 189 gratulate ourselves, but he would have learned—possibly better—without us and our artificial barriers. With adults, however, the barriers to learning have usually become internalized, and the average adult learns very little if left to his own devices. First and foremost, in order to learn we have to acknowledge that there is something we don’t know that might be worth knowing. For a professional programmer, this acknowledgment represents a lowering of status—unless he is perceptive enough to see that a true professional, a person with true strength, loses nothing by admitting to weakness. Some people, however, are only too willing to admit weakness. They, however, will not try to learn because they are convinced in advance that they will fail. Such fear of failure may be engendered by a general lack of confidence, or may spring from the experience of earlier failures in the same kind of endeavor. Most often, however, the fear is not so much of failure itself, but of having other people witness the failure. For certain types of material, being in a group inhibits new learning but facilitates performance in using material already learned. To learn, we must be willing to make mistakes, and this is difficult to do when there is an audience present. Indeed, it is probably the presence of the others that gives the incentive not to make mistakes when the material being used is well known. To the extent that this observation applies to the learning of programming skills, we might expect that initial learning of, Say, a new programming language would best be done when cloistered with a terminal—and when no record is kept of mistakes. Our observations have tended to confirm this prediction in several ways. In one study, which was attempting to determine the most commonly made errors in using PL/I and to examine how well the compiler detected and corrected them, we attempted to collect a// runs made by a group of fifty beginners. The difficulties in making this collection were astound- ing. Every sort of evasion was used in an attempt to cover up the very existence of errors. Although we had explicitly told the group that we were not studying them as individuals and that the purpose of the study was to measure all errors, we continually received the reply: “. . . but you’re not interested in this run; | left off that silly semicolon. Wait for the next run; then I'll have something good to show you.” Another observation pointing in this direction is the enthusiasm that beginners often generate for terminal systems—enthusiasm that often dampens after they reach the point where trivial syntactic errors have all but disappeared through learning. More experienced programmers seem less enthusiastic about the terminal as other than a data entry device —perhaps with mild syntax-checking features to help eradicate keying errors. For beginners, or amateurs, the difficulties with syntax, keying,
190 Programming as an Individual Activity and such auxiliary operations as job control usually far outweigh any deeper difficulties that might arise from subtle semantic points or from the problem itself. Since most psychological tests involving comparisons between terminal systems and batch systems have involved beginners and/or fairly trivial problems, they have failed to give us definitive data on the different strengths of these two approaches. Careful observation of terminal use by programmers in different stages of development and working on different types of problems will be necessary if we are to design systems that are best for initial learning and best for later use. Precious little of the controversy over diverse programming languages and systems ever touches on the distinction between ease of learning and ease of use. There is no particular reason why a feature that is easiest to learn will be easiest to use in the long run. The important con- cept here is that of extensibility of a technique—is it applicable to situa- tions other than the one for which it was first learned? When we learn a general technique, we do not simply add to our repertoire of facts, we multiply our power of performance. At the opposite extreme of general, extensible techniques are what we might term “dead-end” techniques. We may, for example, learn Cramer’s rule for solving simultaneous linear equations by means of determinants in order that we can solve systems of three or four equations. Indeed, this is the normal course of teaching high school algebra. But Cramer’s rule—though in theory perfectly general—is essentially impossible to apply to large systems of equations, for the computation of determinants grows too rapidly in complexity. Although no definite end point can be drawn beyond which it is impractical to employ Cramer’s rule, it is without a doubt a dead-end technique. In programming, we often encounter a programmer who has_ had much success working on problems of a certain size but has never been able to go beyond them. In fact, we sometimes encounter the converse situation—the programmer who was not notably successful until he began to work on bigger systems. In the first case, the techniques that worked so well on small programs just cannot be applied effectively to large ones; in the second, application of powerful and general techniques to simple problems may have resulted in excessive overhead. Consider, for instance, the difference between a binary search and a sequential search. If we are writing a program which has to search through a table of ten items, it will probably slow down the programming and even the execution if we try to apply a binary search. The programmer who does not know of the binary search concept may, on this problem, outshine the programmer who does know it but doesn’t quite have the sense to detect its limitations. All the same, the binary search will probably not be more than half the speed and twice the work—which
Motivation, Training, and Experience 191 cannot be said for the linear search when applied, say, to a list of 1000 items. For the programmer who has mastered certain dead-end techniques (or dead-end programming languages), new learning requires that he give up, at least temporarily, some current satisfaction. His early success with the new techniques will probably not be great; and he is, in a sense, putting himself back on a par with the novices. This fear of loss can be especially great when faced with the learning of a new programming language. Anyone who has ever lived in a foreign country knows the feeling of helplessness the first time he really tries to get along with his meager knowledge of the language; and it is hardly different when one learns to program again. Just as the traveler is embarrassed by the way little children speak better French than he, the experienced FOR- TRAN programmer feels his power slipping away when he has to ask one of the trainees about some simple syntactic point in PL/I. The fear of new things, the expectation of failure, and the reluctance to admit weakness all have a direct retarding effect on learning, whether in a formal classroom situation or on the job. Other problems arise in- directly, most often from an inadequate perception of what has to be learned or how to go about learning it. In one introductory programming course, the instructor noticed that most of the students were having trouble with their laboratory assignments, although they were of a simple nature. Each student was supposed to solve two or three simple prob- lems using a terminal connected to an APL system, but after the fifth week, only about five out of fifty had turned in results. The instructor decided to visit the laboratory, and what he found there were two different problems leading to the same end result—no sig- nificant learning. The first problem involved the students he found in the terminal room. Typically, they had signed onto the terminal the moment they knew how and started typing away. With more confidence than thought, they blundered about for hours and hours of terminal time and got nowhere. The second problem, however, involved the students he didn’t find in the terminal room. In their case, because they were accus- tomed to working problems by hand, they were afraid to come to the terminal before having every last detail worked out. And, of course, they were unable to work out every last detail without the aid of the terminal itself. When faced with a problem arising out of some unfamiliar situation, there are two general errors we can make—either we think the problem is harder than it really is or we think it is easier than it really is. A poor teacher is not usually poor for lack of mastery of the subject matter— Subject matter is commonly in books or other sources, which the students can peruse for themselves. The poor teacher may give his students the
192 Programming as an Individual Activity impression that things are too easy, perhaps by being too smoothly pre- pared so that they do not see the difficulties underlying his examples. Or, he may choose intentionally simple examples to highlight certain points and, in so doing, give the impression that in real problems things always seem to fall into place. In our APL class, the instructor had, to take one example, given a program which found the position of one character string in another— essentially the INDEX function of PL/I. The example presented in ciass took exactly one line, and was quite elegant. Unfortunately, this solution was inadequate in several ways. If either of the strings had only one char- acter, or none, it failed entirely. If the sought-for string happened to be “wrapped around” the sought-in string, the routine incorrectly said that it was found—as in the case of ‘XA’ being found in “ABCX.’’ Many other details had been left out of the problem; but when the students were given a similar problem to do on the terminal, they had to deal with such details even though they didn’t expect them. On the other hand, the same instructor had been guilty of making things seem too hard for other students. At the end of one lecture, finding himself with an extra ten minutes, he attempted to show them a problem he had been working on in his own research. The solution was com- pletely beyond some of the students because they did not have the mathematical grounding even to understand the problem. These students were discouraged from even trying the homework. When there is a teacher, we expect that he will be able to perceive such situations and intervene as necessary to get the students back on the track to learning. But much of programming learning takes place without a teacher, or at least without someone formally designated as one. Moreover, much of programming learning takes place without cer- tain other essential elements—textbooks, reference material, software or hardware on which to run the software, released time to study new topics, authorization to try a new technique on a production problem, or other: programmers who have some experience. Each such missing in- gredient compounds the problem of learning and makes it more likely that the learner will give up at the first discouraging sign. The school is a place where these essential elements are supposed to be supplied. We have no way of knowing how much of the success of a school depends on these factors rather than on its teachers, who form only the most conspicuous part of the teaching system. And yet, although nobody would argue that it is improper for a school to furnish these elements, the very existence of schools may tend to mean that they are not furnished elsewhere. A manager’s reasoning may go something like this: “He’s asking me for a job number to use in running some practice problems. What does he need that for? We just sent him to school for four weeks—what did they teach him there?”
Motivation, Training, and Experience 193 This attitude—“school is where you learn; office is where you work’’— is not, of course, confined to the programming business. Nevertheless, the programming business relies more than any other on unending learn- ing, SO we need not apologize for any attention we pay to factors that stand in its way. HOW TO LEARN PROGRAMMING The programmer who wants to advance himself cannot afford to rely on formal training and the grace of his manager to get the education he needs. Neither can he depend on pure “experience,” for experience doesn’t necessarily teach anything. If a programmer is going to make something of his experience, he must learn how to learn. The first step in learning how to learn anything is to learn your own assets and liabilities—‘‘know thyself.’’ The person who is his own teacher has one major advantage over the classroom student—he can tailor the lessons precisely to the needs of his one and only student. In the pre- vious section, we gave an example of a teacher whose students were failing to learn APL for two different reasons. Not only were the reasons different, they were complementary; for if the teacher tried making things seem harder to help one group, he would lose the group that already was having difficulty in following his examples. Moving in the other direction would be no better, so the teacher was caught in an essential paradox. The only way out of this dilemma would have been between its horns: he would have to deal with each student’s situation individually. This individual attention is precisely what the self-taught student gets automatically, if he but has the self-sensitivity to use it. For instance, every modern theory of education recognizes the existence of favored modes of perception. For example, some people retain (learn) infor- mation better when they hear it spoken, as in a lecture; others retain best when they see the information written. People of the first type may have more success in a class when the lecturer is a fine speaker, whereas people of a more visual bent will be at an advantage when the lecturer has well-prepared visual aids. Most people have an awareness of whether they favor auditory or visual presentations for learning, but few use this information in charting their own educational plans. The person who favors auditory learning should try to find lectures, either live or taped, from which he can learn. If he can find taped lectures, he may have the additional advantage of being able to listen to the same lecture several times—something he cannot do very easily with live lec- tures. In fact, the tape recording—or even television tape recording— promises to give the auditory learner equa! parity with the visual learner,
194 Programming as an Individual Activity who always had the advantage of being able to read a book or Survey a diagram as many times as he thought necessary. The individuality of the learner is not only reflected in his passive ac- ceptance of information from a book or lecture, but also in the activity he performs while using these media. For instance, some people cannot learn effectively from a lecture unless they take notes, even if they never refer to the notes again. The very act of writing while listening enhances retention for some. For others, however, taking notes during a lecture is merely a distraction, and they retain best by concentrating on the lecture as it is given. Such learners are handicapped by being forced to take notes in a course, as when the instructor requires that each student turn in his notebook at the end of the term. When learning individually, how- ever, no such outside pressure is present, yet many people continue to take notes because they were forced to, or taught to, when they were in a formal school situation. Another important dichotomy is between people who learn best by doing—by working problems, writing programs, and so forth—and those who learn best by discussing problems with other people. Of course, the dichotomy is not a genetic one, and we can learn to profit from one form of interaction even if we favor the other. In fact, it may be that we learn different kinds of material best in different modes—we may learn a new programming language best by writing programs in it, but we may come to understand a problem best by discussing it thoroughly before plunging in. One final area in which idiosyncratic learning methods should be Studied is that of work habits. Some people learn best first thing in the morning, and some “night people” pass their early morning hours in an impenetrable fog. Some people learn best when seated in a hard straight- backed chair at a desk, whereas some hedonists in such a situation can- not take their mind off their discomfort long enough to learn that one plus one is two. Some people like to write with a hard pencil, some with a soft one. Others must have a fountain pen, a ball-point, or a felt-tip; still others must have a typewriter—and a particular model, to boot. Some people prefer unlined paper, some prefer wide-lined, some prefer narrow. Still others like to use graph-ruled paper, at least for some types of work. One programmer must code on a preprinted coding sheet, another must use plain paper, and yet a third might prefer composing his programs on a typewriter, or a terminal. Even in the case of terminals, some prefer a graphic terminal, and others must have a hard copy produced before their eyes. One of the reasons for preferring a graphic terminal is that some people cannot work well in a noisy environment, and yet we know that others actually need a substantial amount of noise in order to learn at all—even to the extent of having to play a radio while they study. The debate over the optimum conditions for learning is probably end-
Motivation, Training, and Experience 195 less, for it is essentially a debate over an unresolvable problem. When we are establishing a school, it may be necessary to accept one mode of Operation as best compromise for the ‘‘typical” student, but why should an individual working alone have to make any compromise whatsoever with the conditions that will be optimal for him? Indeed, even in schools the quest for efficiency is often carried beyond any reasonable need. Why, for instance, must all students be forced to work on the same type of terminal, the same type of coding pad, or with the same type of pen or pencil? Making several reasonable alternatives available in the school situation should encourage students to think about their own learning habits—so that when they leave the school they will be better prepared to continue learning, rather than feeling that if they never study another thing it will be too soon. No matter how well we establish the best physical environment for learning, they have little influence on our success if we do not use all the information available to help us learn. Just as we lose efficiency by ignoring our idiosyncratic needs, we lose when we ignore sources of in- formation—or pieces of information lying available in sources we are already using. Probably the greatest cause of this type of loss is the concept that something that is not “right” is ‘“‘wrong.” This binary distinc- tion—this Aristotelian fallacy which pervades our culture today—results in countless amounts of lost information, which, if recovered, could lead to a major increase in educational efficiency. As a simple example of such loss of information, consider the case of two students trying to do the arithmetic problem, 25- 16, on a test. If one student gets the answer ‘‘19’’ while the other gets ‘‘41,” both are graded as being ‘“‘wrong,” yet the first is obviously suffering from a different problem than the second. In a large class, these two students are merely lumped together as ‘“‘pupils who cannot subtract.’ If either were for- tunate enough to have a tutor, the additional information in their answers would be turned to good teaching advantage. When we undertake to tutor ourselves, we must learn to pay attention to all such information. When we write a program, for instance, and when that program does not run “correctly,” there is usually a plethora of information lying about in the output. Rarely, if ever, do we just get back a program which says “incorrect,” although many programmers operate as if this were all they had to work with, and all they care about. If, on the other hand, the output seems to be ‘‘correct,” they lay it aside without a further thought. Learning is an active pursuit. When learning to program, there are two times when one should actively pursue learning—when the program runs and when it doesn’t run. When it runs is the time to step back three paces and take a broad look at what has been accomplished. Why was this pro-
196 Programming as an Individual Activity gram successful when we have had more trouble with seemingly similar programs? Why did we have as much trouble as we did? If we were start- ing from scratch, what would we do differently to make the programming job easier, or to make the program more efficient, or to make the docu- mentation better? Can we do any of these things now? All too often the program that ‘‘works” is mistaken for the program that is finished, fre- quently because of management pressure to ‘‘produce.’’ But the pro- grammer who wants to learn must resist such pressures and take the time to review his success. It might be a good practice for management to give the programmer a day off when his project is ‘finished,’ not so much as a reward but as a chance to get a little perspective. When our program does not run correctly, we have the opportunity to learn more specific lessons. Quite often, under the pressure of produc- tion, the programmer is tempted to bypass a trouble spot with a ‘‘fix’’ that he knows will work, since it does not use some new technique which he was trying to master. Suppose, for example, that he has just been study- ing array expressions in PL/I, but that he has some trouble with an array expression in his production program. If he decides that array expressions are too “complicated” and substitutes a DO loop such as he has been using since his FORTRAN days, he will have missed a golden opportunity for learning. No time will be more propitious for learning than that time at which the need for learning is felt most strongly—the very moment when we detect an error. But be realistic: production work comes before learning in most en- vironments, and managers will not tolerate substantial current delays even when promised ultimate rewards in the great beyond when the new technique is mastered. What is the programmer to do when faced with this conflict between his job and his learning? Actually, the resolution is simple. If, after a reasonable amount of time trying to understand the failure of the new technique, he has had no success, he should proceed with his ‘‘fix,” if he has one. At the same time, he should construct a test case that will enable him to discover why his original approach failed. In our example of PL/I array assignments, the programmer could write out the DO loop in the production program and initiate a job in which the array assignment is tested in isolation. By pursuing this test example to the point where he understands the problem, he will not only learn the one thing he did not know, but perhaps will learn others as well, for test programs such as this are often better learning instruments than are production programs. As a matter of good practice, the test program should be constructed before the ‘fix’ is made to the production program. In the first place, there will be an all too human tendency to forget about the problem once
Motivation, Training, and Experience 197 the production program is working correctly, so we must impose a little discipline on ourselves. Possibly more important, however, is the chance that by the mere act of constructing the test case we shall discover the problem. In one case we observed, the programmer had been having trouble with the PL/I array assignment statement A = A/SUM(A); He did not know where the trouble lay, so he created a test case in which the SUM function was applied separately, in order that he might see the sum printed. As he did this, however, he suddenly realized that SUM(A) would not be computed separately in the problem statement— that it would, indeed, be computed after each assignment of an element of A. He was able to check this idea against the erroneous output (using more of the information than he had originally when he just perceived the result as “wrong”) and confirm his hypothesis. The production program was then corrected to read B — SUM(A); A = A/B; He had not only learned something, but his production program reflected his new insight. Moreover, he had overcome a substantial proportion of his fear of array statements, having met the beast in mortal combat and emerged victorious. In the construction of ‘‘learning cases,”’ the programmer has to develop a feeling for the ‘‘critical case’ —that is, the case that is just like the case at hand except for one critical difference. Through the contrast between these two cases, he learns precisely how much discrimination he must make—neither more nor less. For instance, if he is having some trouble with the expression INDEX(X||‘ABC’, ‘ABC’); and is unsure of the INDEX built-in function, he can construct several minimally contrasting cases in his test program, each differing from the Original in one aspect. Thus, for instance, one case could use a variable instead of an expression as the first argument, a second could use a String of different length, a third could use a variable second argument. Each case gives him information somewhat different from the others, and by running several cases at once, he increases his chances of obtaining the information he wants in a single run. To implement such an active program of learning, the programmer must already know quite a bit. If, for example, he does not have sufficient proficiency with his programming language to make the construction of a critical case a relatively simple and foolproof affair, he will quickly become embedded in a morass of detail, which he cannot possibly handle on his own. It should, therefore, be the goal of formal educational pro- grams to train the programmer to the point where he can use his tools as tools to further his learning. Instead, we all too often find that the
198 Programming as an Individual Activity formal education has merely served to inculcate in the programmer a hatred for his tools. How many college graduates take their diplomas with the secret thought that now, at last, they are freed from such things as books and lectures? It is a poor workman who hates his tools—all the more because it is the tools themselves which can teach us to become good workmen. SUMMARY The two major influences we can exert on a programmer's performance are on the desire he feels for working and on what he knows that is needed to do the job. The first is called motivation and the second is called training, or, if it is sufficiently general, education. But little is known about why programmers program harder, or even whether they are already programming too hard for their own good. Possibly even less is known about educating programmers, even though vast sums have been spent on training schemes. Indeed, more articles and books have been written on programming education than on all other aspects of programming psy- chology put together, yet few of them have any lasting importance. Perhaps we expect too much from formal training—from schools. The education business is still essentially medieval in its practices, so why should schools for programmers be different? Typically, where there is a carefully worked-out educational program, it is to train future professionals with amateur habits, so perhaps it is better that they don’t do much of a job. At least there’s less to unlearn once you get into a real program- ming environment. The one factor that saves us in the computing education business is the computer itself—ever silent, ever patient, ever teaching the program- mer who has but the skill to learn. Perhaps we should set as a goal for our schools merely to leave the students alone, so that they do not turn off to learning before they get on the other end of that log with the real teacher of us all. It may be expensive, it may be inelegant, it may be old-fashioned, but for programmers, computer assisted instruction (but not CAI!) is still the best. QUESTIONS For Managers
- What is your impression of what motivates your programmers? Is it the same thing for all of them—for men and women, for old and young? Do you assume that they are motivated by the same things that mo- tivate you?
Motivation, Training, and Experience 199 2. Do you take steps to keep your programmers from overworking, from getting too involved in their job? Do you ever envy their involvement, their dedication to their work? 3. What are your attitudes toward providing resources for programmer education (not necessarily programmer schools)? What do you do to encourage your programmers to educate themselves as they work? Do you do this just as an excuse not to spend money on schools? 4. Do you encourage programmers to work in their own preferred modes? Do you, for instance, permit programmers to have different sorts of equipment in their offices, to take work home, or to shift their working hours from the normal working hours of the shop? For Programmers
- What things could your manager do for you to make your work faster or better? Have you ever discussed these things with your manager? If not, do you think he understands which things they are?
- Write a personal history of your training in computer programming. Make notes of which experiences taught you which things, and which were most beneficial to you. On the basis of this list, what are you going to do about your future education? Or do you already know everything there is to know about programming?
- What are your favored modes of perception? What do you do to try to take advantage of them in your educational effort?
- Do you have any ‘peculiar’ work habits which you think enhance your performance? Does your manager permit or prevent you from working in these ways? Does your manager know of your preferences? BIBLIOGRAPHY Sackman, Harold, Man-Computer Problem Solving: Experimental Evaluation of Time-Sharing and Batch Processing, Princeton, N.J., Auerbach, 1970. Again, Sackman has a number of important things to say about programmer training, and his largest and most recent studies were carried out on trainees at the Air Force Academy. One of his observations, which bears out the point of view of this chapter, is that by far the most desired improvement to help cadets in solving programming problems was ‘improved instruction.” Part of the prob- lem, | suspect, is the restriction to individual work, which is particularly em- phasized at the Academy. Thus, group cooperation in learning, which is essential in any real programming effort, is set aside by the school as “cheating.” See also the last chapter, which Sackman relates some of his findings to the general psychological literature. He seems to feel that in the end, for program- ming, experience and training come to dominate all other variables in programming success. Cofer, C. H., and M. H. Appley, Motivation: Theory and Research, New York, Wiley, 1964.
200 Programming as an Individual Activity Covers the multifaceted motivation theories in a professional way. A good place to start into the classical work in the field of motivation, as seen by psychologists. Hilgard, E. R., and G. Bower, Theories of Learning, 3rd ed. New York, Appleton- Century-Crofts, 1966. This book does for psychological learning theories what Cofer and Appley do for motivation. Again, a good place to start on an endless topic. Proceedings of the Computer Personnel Research Conferences, Association for Computing Machinery, New York, published annually. Articles on training schemes and systems for programmers are scattered through- out the computing literature like plums in a pudding. The articles on training in these procedings should give the reader enough of a sample to make up his own mind. Hall, Douglas T., and Edward E. Lawler Ill, Job Pressures and Research Per- formance, American Scientist, Vol. 59 (Jan.—Feb. 1971). Aithough we still do not have a study of the effect of job pressures on program- ming performance, the programming manager might profit from reading this article, just so long as he keeps a slight reservation in the back of his head that programming is not, so far as we know, the same activity as “research.” At least this article shows that for complex intellectual activities, the relationship between various job pressures and productivity is not a simple one, and is oversimplified only at a manager’s peril.
Silver Anniversary Notes I, Comments on Chapter 10: Motivation, Training, and Experience From MBTI personality theory, | learned much about motivation that | didn’t know twenty-five years ago. | now understand, for example, that my type (INFP) is quite likely to be galvanized by the idea of helping people learn for them- selves—as was my objective in writing this book. Other MBTI types might be equally motivated to write a book on the same subject, but for very different rea- sons. An INTJ type, for example, might want to show how programming can be stripped down to a few essential, elegant models. The MBTI model certainly doesn’t explain every idiosyncratic motivation—not by a long shot. Some people would do almost anything for a ticket to a Michael Jackson concert, but for me the ticket would have to be to a Michael Jordan per- formance. No theory will explain our individuality, but the astute manager can easily figure out what motivates each individual—by asking! Of course, this approach requires a type of manager-employee relationship not accessible to certain management styles. Such managers will simply have to guess what motivates their people. One rather striking change among programmers in the past few decades has been the reduction in diversity of schooling. Today, a systems programming team is likely to contain quite diverse individuals, but most of them will have been formally trained in “computer science.” Last year, for instance, while consulting with a large software company, | worked with a team of five developers (not systems programmers, though), all of
aS Silver Anniversary Notes whom had graduate degrees in computer science. Only two, however, had gone straight through school. Two of them had run successful businesses of their own before coming to work for this company; one had his own Bluegrass band on the side; one was going to law school at night, hoping to practice family law; and the fifth, who had learned programming on his own at age twelve, worked for the com- pany for five years before he was sent back to school to get formally educated. Most interesting, however, was the coincidence that all of them had learned to program before they studied programming formally in school. That’s a major change brought about by the personal computer. In my day, | had not even seen a computer before | went to work for IBM in 1956. Before that, while an under- graduate, | had worked for the physics department as a computer—| inverted 10x10 matrices by hand, and “computer” was my job title. My children’s generation had access to computers in school, and my son Keats took his degree in computer science. Nicolas, my grandson, has the advantage of this marvelously patient teacher before he has even entered school. Perhaps his psychology of programming will be different, but we’ll have to wait for the Golden Anniversary Edition of Psychology to find out.