54KB
The Psychology of Computer Programming — Chapter-08: Personality Factors
- Source: /library/The Psychology of Computer Programming/source-file.pdf
- PDF pages: 191–212
- 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.
PERSONALITY FACTORS n one sense, the concept of personality encompasses ail the individ- ual variations we find among people. Even to the most casual ob- server of human behavior, it is evident that intelligence and education affect personality. When we use the term ‘personality’ in the sense of the previous sentence, we mean the totality of personal character- istics by which we ordinarily identify people—a kind of summary of the person. In this sense, one’s personality is one’s identity, a concept which is neatly illustrated by a study done in one computing installation. The Mad Bomber In a remote batch environment, the operators in the machine room may rarely, if ever, interact directly with the programmers whose jobs they run. Under the circumstances, we might expect that operators will not 141
142 Programming as an Individual Activity know much about the personalities of their programmers, but this is not the case. Personality, being the totality of factors contributing to our individuality, is displayed in everything we do or say. In particular, it is reflected in our programs, and, even more particularly, in how those programs look to the machine operators. The chief systems programmer, who, by the nature of his duties, was in face-to-face contact with both programmers and operators, had ob- served that the operators often had disparaging comments to make about certain programmers. As he was attending our seminar on ‘The Psy- chology of Computer Programming,” he decided to study these comments with an eye to correlating them with specific programming practices. His most interesting findings, however, had to do with the personalities of two of the programmers. Of the seventy or so programmers using this machine, these two stood out in the comments of all the operators. Even operators who worked on different shifts and therefore had no opportunity to discuss such matters agreed that these two programmers were worse than any of the others. Upon further investigation, the chief systems programmer found that these opinions had been formed largely on the basis of the abnormal terminations—dumps and “bomb-outs” of the entire system. Such ab- normal terminations were extremely rare events—except for the work of these two individuals—and they were also most annoying to the Operators. As there were no regular channels by which the operators could communicate with these programmers, they could only curse among themselves each time a ‘“‘bomb-out’ occurred. The systems programmer began to save examples of these disaster situations, and after he had gathered enough to form a definite pattern, he interviewed each of the two programmers. The first one, he discovered, was an engineer who had no programming training whatsoever. His en- gineering group was highly dependent on the results from a single pro- gram. This program had been left in charge of the engineer when the Original programmer had left. Not knowing anything about programming —and being too shy to ask for help—he ran the program on a trial-and- error basis, changing now one card, then another, until he got the re- sults he wanted. In the process, he was giving the operators fits, though he was, quite naturally, unaware of any disturbance. The second programmer—the worst offender of the two, and affec- tionately known among the operators as ‘‘the mad bomber’—turned out to be a rather different case. Not only did he have programming ex- perience—he had fifteen years of it. In that decade and a half, he had —according to him—programmed eleven different machines in fourteen different languages. Moreover, he was—again according to him—an ex- pert in all of them. Small wonder his programs bombed the system: they
Personality Factors 143 were far too abstruse to be understood by mere operators or to be handled by some operating system which he himself had not written. The number of times this expert’s programs bombed the system had evidently been magnified by a factor of three or more by the simple expedient of resubmitting the offending decks without change. According to him, the probability was so small that his programs could be wrong that it wasn’t worth his precious time to look at them until they had been rejected three times in a row. At that point he would stomp into some other programmer’s office and demand to know why the system was not working properly. Even after his errors had been patiently pointed out to him, the bomb- ing was not finished. In one example, found by the systems programmer, the bomber had made an error in job control in the first step of a three- step job. After having been shown the error and how to correct it, he resubmitted the job only to have it bomb the system once again. Back it went for another bombing, and another, after which he had the same error pointed out in the second step of the job! And even that was not enough. The whole cycle was repeated for the third step, which—as we might have guessed—contained precisely the same error. Both of these cases are archetypical examples of how personality affects programming performance, although the personalities in the two cases are as different as a mouse and a lion. The engineer’s bombing problems were solved by sending him to a programming course—giving him the aid he was too shy to request for himself. For the “expert,” however, education was no solution. Inasmuch as he held an absolute faith that he knew everything about programming—or at least everything worth knowing—he could not be convinced to attend a course or even to listen to the advice and counsel of anyone else. Eventually, his problem was “solved” by permitting him to take his services elsewhere, and, for all we know, the “mad bomber’’ still lives today. PERSONALITY CHANGES Although there exists no universally accepted definition of personality, we can take the following* as a good working model for our study of personality as it affects—and is affected by—programming: Personality is the integration of all of an individual’s characteristics into a unique organization that determines, and is modified by, his attempts at adapta- tions to his continually changing environment.
- D. Krech, R. S. Crutchfield and N. Livson, Elements of Psychology, 2nd ed., New York, Knopf, 1969.
144 Programming as an Individual Activity The first thing in this definition that may surprise some readers is the clear statement that personality is not fixed. Nevertheless, there is a certain enduring quality to personality, and therefore personality does not change when there is no reason for it to change, although it may some- times seem that way. For instance, a relatively mild-mannered and amiable programmer began to shun his fellow workers and to react rather testily to attempts to help him in his work. Such behavioral changes often arise quite slowly, and considerable time may elapse before we recognize the change. Sometimes, in fact, the condition engendering them is a transient one, and the behavior change reverses itself before we have had time to identify it as a “change in personality.’’ But when a change persists, there is always a reason behind it, although the reason may not be related in any direct way to the actual behavior. In our example, the change in the mild-mannered programmer came to the attention of his manager through the complaints of other pro- grammers. In an interview, the programmer acknowledged that he had noticed a change in his behavior, but was at a loss to account for it. The manager speculated on the cause, but had no more success than the man himself. After a few weeks, however, this programmer had to leave work early with a racking toothache. Upon visiting a dentist— something he had failed to do for several years—he was informed that four of his teeth were so badly infected that they would have to come out immediately. Within a week after the extractions, his former sweet self had emerged, the source of his transformation having been the debilitating effect of the infection upon his health. Unfortunately, it is easier to identify the source of a personality change after the fact than before. We cannot conclude that whenever a friendly person turns unfriendly he should have a few teeth removed. The same personality change could have come about from any number of causes— physical, mental, or strictly external to the man himself. In one instance, a man attending programming school was doing very poorly, in spite of the fine recommendations he had brought with him from his home office. The director of the school was about to fail him and send him home, but first took the trouble to take the man to lunch to give him a chance to account for himself. Not until dessert was served did the poor student reveal the fact that his wife—1500 miles away—was dying of cancer. Going to the school had represented an important opportunity for his advancement, and his wife had insisted that he go. But, though he tried to fulfill her wishes, he was unable to concentrate on study. Not wishing to earn special favors for himself, he had not told anyone at the school of the situation. Were it not for the director's patience, he would have been sent home in disgrace for no more of a crime than being distraught over his wife’s dying.
Personality Factors 145 Situations such as our last two examples present a grave moral dilemma for a manager, at least in our society where one’s “private life’ is not Supposed to enter into office affairs or be examined by one’s manager. However, since there is no way to determine from the symptoms whether the cause lies in the office or out, a manager has no choice but to try to understand behavior that is disruptive to the work at hand. If the source of trouble does lie in the office, it may prove an easy matter to rectify. Perhaps the programmer does not get along with his office mate. Unless he is unable to get along with any office mate, the “personality” problem can be erased by a change of venue. Even if the source of difficulty cannot be so trivially removed, an ad- justment may at least alleviate the problem. For example, if a pro- grammer has become irascible in his dealings with the machine operators, it may be a result of pressures put on him to complete a troublesome program whose bugs he cannot locate. If he tends to be an assertive per- son, he may be unwilling to admit that he is having trouble at all, much less to seek assistance. Prohibiting him from entering the machine room will only eliminate the symptom, and his trouble will shortly manifest itself somewhere else. If the true source of difficulty can be detected, he may be given assistance without his having to admit that he is in trouble. He may be annoyed at this impugning of his programming ability, but once the bug is found, he will probably soon forget it. We all feel, at times, that a strong medicine is worse than the disease, but at least its effects are over sooner. In all of these cases, no effective action can be taken to correct or adjust for a personality problem without uncovering its true source. Psy- chological awareness can help in locating the source of such a problem, but psychology has not developed to the point—and never will—that it can be used for diagnoses without the aid of the person himself. Nobody can tell from watching a man work that his wife has cancer, or that his teeth hurt, or that he fears he will not meet his deadline. No manager will be successful if he tries to make psychological judgments of people on the basis of external symptoms. But, if he takes those symptoms as indicators to attain further information before taking action—information which can only be obtained, if at all, through the people themselves—his actions are quite likely to be rewarded with success. PERSONALITY INVARIANTS If personality “is modified by ... attempts at adaptation,’’ we can use personality changes as signals that a person’s environment has changed. But changes in personality—although they may represent extremely
146 Programming as an Individual Activity serious situations—are not that frequent. What may be of more concern in the long run is the way in which a programmer’s more or less in- variant personality affects his work as a programmer. One popular view of personality—popular both with psychologists and with the man in the street—is that personality may be characterized by a collection of traits. This person is said to be ‘‘conservative, stable, and shrewd,” and another is described as “shy but imaginative.” The in- tuitive appeal of such descriptions is compelling, and we might be tempted to try describing the traits that make up the ‘ideal programmer personality type.” Because of the variety of situations that are subsumed under the name of “programming,” the best we can hope for is a relation between certain traits and certain types of programming work. We need not discuss the various “‘trait theories,” for we are not seeking such exactitude, even if it existed in the theories. Also, if the theories are controversial, or inexact, that need not mean that they are not suggestive. For example, one pair of traits often used is ‘‘trusting- Suspicious,” and we might ask ourselves at which end of the spectrum it is best for a programmer to be. Clearly, when one is debugging, it is best to be suspicious, almost to the point of paranoia. On the other hand, in any work with other people, it is best to have a certain amount of trust, for people who are not trusted are not trustworthy. In some situa- tions, however, these two needs come into conflict. If a programmer works in a “product test” group, he must be suspicious of other people’s programs. If someone tells him, ‘‘Don’t bother to check that. | fixed it up and checked it myself,’’ his impulse as a trusting person is to believe, and the requirements of his job are to be suspicious. The product test programmer, then, is in a quandary, but how serious this quandary is depends on his other personality traits. If he has a great need to be liked, it will bother him to have to seem to show unfriendliness by calling someone’s word into question. But, if he is of more independent mien, or even a bit antagonistic to other people, suspecting others’ statements about their programs may not bother him a bit. Thus, all other things being equal, certain people will find the job of product test pro- grammer easier psychologically. As usual, all other things are never really equal. Such personality traits as emotional stability or instability will affect how well a person can tolerate being in any paradoxical position for an extended period. Because the period of time is important, a manager can, by changing work as- signments more frequently, relax the stringent personality requirements that might otherwise be necessary for the job of product test programmer. This type of alternation of jobs is accomplished automatically through egoless programming, for no person is subjected to unrelenting assault on his particular personality—the type of assault that forces people into “attempts at adaptation.”
Personality Factors 147 Through egoless programming, then, we sacrifice the possibility of having each person always in the job for which his personality best suits him, yielding, in this way, some potential efficiency for security and stability. Moreover, the full potential for efficiency may not be lost, since we are not likely to have had the perfect mix of personalities in the first place. Then, too, “‘wearing the other man’s moccasins” has always been a good way to develop the personality trait of tolerance. Attempts to place each person in the job best suited to his personality are subject to failure from another direction. Personality is not simply a single surface layer, but runs through many layers. Identical surface layers may conceal rather different—even quite opposite—interiors. A “friendly” person may seem that way because he is anxious to present a good impression of himself in a situation where he is insecure; or, his friendliness may be a manifestation of his complete relaxation in the situation. Evidently, we must be more than a little cautious in inferring the inner layers of personality from simple observations of the outer. Another factor that distorts our perception of someone’s personality is that many people tend to show a different face to people in authority than to their associates or to their employees. Also, many people behave differently with people for other reasons, such as sex or age. An amusing instance illustrating this principle occurred late one night in the test cell of a computer manufacturer where a programming team was testing a new machine. At about two in the morning, a plant guard discovered the team at work, and he became quite upset and a little arrogant as he explained to the group that women were not permitted to work in the plant after midnight. One of the three young men in the group rose to the defense of his manager—the one female among the four of them. “You mean there are no circumstances under which a woman can work here after midnight?’’ he demanded. “None,” was the reply, clothed in tones of authority. “You'll have to get out of here immediately. I'll escort you to the exit.” “But we have permission of the plant manager. We must work at night because the machine is not available during the day.” The mention of the plant manager introduced a faint note of uncer- tainty in the guard’s answer: “The only time a woman can work here after midnight is when a manager is present.” Then, surveying the four members of the team and reassuring himself that not one was over thirty, he regained his positive voice. “But there is no manager here, is there?” At this point, the female member of the team stepped forward and with her most seductive smile and managerial manner of speaking said, “But / am the manager of this group.” The guard’s confusion was so great that he lost control of his jaw, which simply hung open for a few moments while he considered the implications of a woman, a young woman, an attractive woman, being a
148 Programming as an Individual Activity manager. When he regained his composure, his voice was soft and subservient. ‘‘Oh, | see. | beg your pardon, ma’am. I’m sorry | disturbed you. If you’d like, I'll come around here every hour or so and see if things are all right.” Sensing his discomfort, she, too, softened her tone to one of managerial largesse. “That won’t be necessary, I’m sure. But thank you for offering. We appreciate the job you’re doing.” It was a clear dismissal, and he understood it, turning around without another sound and walking Off into the dark recesses of the empty test cells. If he had had a tail, it would have been between his legs. Now, a plant guard is not a programmer and may not be as familiar as programmers with the common programming situation of women, young women, or even attractive young women in positions of authority. Nonetheless, programmers as well as plant guards have personalities— personalities that change their external appearance in response to the perceived social roles of the people around them. We should not be surprised, then, when a manager is unable to understand why a pro- grammer who, with him, seems the very model of friendly, quiet coopera- tion is, with his co-workers, aggressive, noisy, and generally difficult to get along with. CRITICAL PERSONALITY TRAITS Measuring personality is difficult, and matching personalities to job descriptions is perhaps even impossible; but isn’t there some way we can select those people whose personalities suit them for programming? After all, if personality is important for programming, we cannot just give up without trying. Perhaps we can gain something from consideration of extreme cases, even if we cannot do very much with the general case. The nature of the way that personality interacts with programming success is subtle, but we probably can make some assertions about how personality traits may lead to programming failure. Although the average programming manager would say that intelligence is more important than personality in programming success, very few could cite cases of people who turned out not to be intelligent enough to program, but everyone knows of cases of people who were not temperamentally suited to the programmer’s job. It is in this sense that we can assert that personality is more important than intelligence in programming. lf we look more deeply into the observed dominance of personality factors in programmer failures, we can easily understand why we are more likely to make a personality mistake in hiring a programmer than an intelligence mistake. In the first place, there is an enormous amount
Personality Factors 149 of preselection of people, which places limits on who is likely to be making application for a programming job—even as a programming trainee. Part of the preselection is imposed in explicit hiring policies, such as requiring a college degree, or even a degree in specific fields. Possibly even more important is the self-selection that takes place be- cause the uninitiated beiieve that programming requires ‘“‘a lot of math.” Not too many years ago, the external perception of programming was so distorted that young men were advised to ‘‘study electronics’ if they expressed an interest in working with computers. Young women, of course, were automatically excluded by this criterion, for young women did not study to be “engineers.”’ Whatever the faults of this preselection in excluding people who might have made great success as programmers, it does have the effect of largely eliminating people of below-average intelligence. Such people, if they had presented themselves for jobs as programmers in great numbers, might have failed in great numbers, making us feel a need to measure intelligence of programmer applicants. But is there no comparable selection process on the basis of personality, as well? No doubt there is, but personality has many more dimensions than in- telligence—although intelligence is not by any means measurable by a simple score on an IQ or programmer’s aptitude test. Thus, selection on a personality basis is not likely to produce such uniform results with respect to the needs of programming. Moreover, even if the schools, say, did make a personality selection as strong as an_ intelligence selection (and, make no mistake, school success involves a large element of personality), personality is more changeable than intelligence. In fact, one of the few really reliable things psychologists can say about these two aspects of a person is that intelligence is much less responsive to environment than is personality. Marriage, for example, is not likely to have a measurable effect on a college graduate’s intelli- gence, but it will most assuredly provoke personality changes that can be perceived even by the untrained eye. Thus, a man who was a frivolous playboy in his fraternity days might well surprise us with the con- scientious programming job he now does; but if he was unable to write a simple declarative sentence in college, marriage and family will probably not help one bit. What traits, then, would give an indication of potential failure in a programmer? We can speak on this subject only from anecdotal material, for there have as yet been no formal studies of this question. Nevertheless, we can probably say with assurance that someone without the ability to tolerate stressful situations for a period of a week or more is not good programmer material—given the realities of programming work today. We are speaking of professional programming, of course—where the
150 Programming as an Individual Activity work and schedules are imposed from the outside. Amateur programming is not such a stressful pastime, possibly because one’s entire career does not seem dependent on finding a particular bug by next Thursday. Because of the diversity of programming work, people who are not in some measure adaptable to rapid change will probably have trouble as professional programmers. It is unlikely that a programmer will go through a month—not to speak of an entire career—without having to face the psychological shock of having his work pulled out from under him, or at least changed sufficiently so that his previous efforts become garbage. And speaking of garbage, one of the most easily identifiable personality needs in programming is a modicum of neatness. We are not speaking here of personal grooming, though in one case a programmer actually smelled so bad that nobody could sit next to him long enough to look at his listings. What we mean is a slight compulsion to keep one’s papers in order, without which the computer’s paper-generating capacity in- exorably leads to grief. One computing center selects its programmer trainees by giving a test and choosing the candidate who turns in the neatest paper, not the one with the highest score. Another essential personality factor in programming is at least a small dose of humility. Without humility, a programmer is foredoomed to the classic pattern of Greek drama: success leading to overconfidence (hubris) leading to blind self-destruction. Sophocles himself could not frame a better plot (to reveal the inadequacy of our powers) than that of the programmer learning a few simple techniques, feeling that he is an expert, and then being crushed by the irresistible power of the computer (the Deus ex Machina). The other side of the coin of humility is assertiveness, or force of character. A programmer’s job is to get things done, and getting things done sometimes requires moving around obstacles, jumping over them, or simply knocking them down. The humble person is acutely aware of the ways in which he may be wrong; his critical mind tends to dominate his force of character. Now, although it is true that force of character without a critical mind is like a steam boiler without a safety valve, a critical mind without force of character is like a safety valve without a steam boiler. There is no danger of explosion, but then there is no possibility of getting any work done, either. We have some empirical evidence from an unexpected source on the question of humility versus assertiveness in programming. In perusing the data from our study designed to test the effect of instructions, we plotted the lengths of time each programmer spent studying his runs from the batch system. When length of study period was plotted against fre- quency, we found we had two distinct types of graph, as shown in
Personality Factors 151 “ASSERTIVE” Frequency of work periods plotted against log base 2 of period length in minutes (e.g., 1 means 1 minute, 2 means 2 minutes, 3 means 4 minutes, and 5 means 16 minutes) Figure 8-1 Two programmer personalities.
152 Programming as an Individual Activity Figure 8-1. The top graph shows only one peak in the plot of frequency versus logarithm of time period, and the second shows this peak with another peak added at the low end. This second peak is a preponderance of one-, two-, or three-minute work intervals, which we were able to track down to corrections of careless coding or keypunching errors. We took the trouble to look for such a pattern in other work, particularly when we were studying errors in PL/| syntax. Previously, we had over- looked this pattern because we only asked the programmers in the syntax study to turn in runs with errors. When we started collecting all runs, as we had in the “instructions” study, we saw the same pattern in a different way. Certain programmers, once they got out their original syntax errors, essentially never made another syntax error. As they made their modifications, one or two at a time, they carefully and methodically checked and punched them so that every run after the first few was free of syntax errors. The other programmers, however, and they formed about one-third in this group, consistently fell into a pattern of hasty changes so that two runs were almost invariably required to make a single correction. After the first run, the programmer would make a one- or two-minute work period to fix the syntax error he would not have made in the first place had he been inclined to a more humble view of his abilities. In Figure 8-1, we have taken the liberty of labeling the one graph “humble” and the other “assertive.”” Although the patterns are definitely there, and although they are stable patterns (the same programmer does the same thing on different programs), we really cannot yet say that these patterns correspond to the traits “humble” and ‘‘assertive’’ as measured by some standard psychological testing instrument. This is a clear area for further research—research that will be important, for ex- ample, not only in the selection and training of programmers, but in the design and evaluation of on-line systems. We might conjecture here that “humble” programmers perform much better in batch environments, and “assertive” ones will be more likely to shine on-line, where their assertiveness will not be severely penalized, and their willingness to push ahead will blast them through problems that will leave the ‘‘humble” programmer just gaping at the terminal. Last among the essential personality traits for programming, we might list sense of humor. The computer ‘‘doth make fools of us all,” so that any fool without the ability to share a laugh on himself will be unable to tolerate programming for long. It has been said with great perspicacity that the Programmer’s National Anthem is ‘‘aaaaahhhhh.”’ When we finally see the light, we see how once again we have fallen into some foolish assumption, some oafish practice, or some witless
Personality Factors 153 blunder. Only by singing the second stanza, “ha ha ha ha ha,” can we long endure the role of the clown. PERSONALITY TESTING The impressionistic picture we have painted of the ideal programming personality—ideal by virtue of exclusion of extreme traits that should lead to failure—is not the usual one of a “rigid’’ person. There seems to be some current folk wisdom which imagines that, because pro- grammers work with rigorous machines, they must themselves be rigid. In effect, the opposite is true, for since the machine is so inflexible, the programmer must be flexible enough to supply the elasticity needed in matching any system’s abilities to real world needs. Is it possible, then, that we could introduce some system of personality testing to help us overcome our folk prejudice in the selection of programmers or pro- grammer trainees? There exist today a number of “personality tests,’’ some of which have been used on occasion to aid in the selection of people as po- tential programmers. A number of these have been developed for, and used primarily in, the detection of personality disorders—the famous Rorschach Ink Blot Test, the Thematic Apperception Test (TAT), and the Minnesota Multiphasic Personality Inventory (MMPI). The MMPI, for instance, was developed on the basis of empirical information arising in part from a study of institutionalized psychotics, since their personality characteristics had supposedly been well determined by trained psycholo- gists and psychiatrists. ‘Normal’ people were also used, but the main thrust of the MMPI was to aid in diagnosis of mental illness, not in dif- ferentiating among various ‘‘normal” personality types or traits. Naturally, we feel that mentally ill people are not what we are looking for when we hire programmers—although there are no empirical data to support or contradict that view. The question of whether to use this type of test for hiring programmers, however, is not one of effectiveness or appropriateness, but simply one of the ethics of normal hiring practices. Is it appropriate to give tests for mental illness to anyone applying for any kind of job? The answer to this last question is not limited to programming, so we shall sidestep the ethical issues involved. But what about personality tests that have been devised as a way of selecting people for jobs or even for careers? A typical examination of this type is the Strong Vo- cational Interest Blank. (Strong is the name of a man, not an adjective suggesting that the test measures strong interests.) In tests such as
154 Programming as an Individual Activity this, interpretations are based on a comparison of “‘scores’’ with sets of scores obtained from people already in various professions. Thus, if a career counselor had given this test to a high school student, he would compare the student’s score, or profile, with profiles considered “typical” of various professions. The counselor tries to determine the professions that most resemble the student in profile, and then, presumably, he recommends that the student choose his career from among that set. In hiring, of course, the employer is usually interested in one or, at most, a few types of work. By comparing the applicant with each ap- propriate profile, he may make a judgment as to whether or not that applicant possesses a Suitable personality for the job. Now, how suitable is this procedure likely to be, given what we know about the relationship of personality to programming? The first weakness of this procedure is that there may be no profile for the group called “programmers.” A number of firms have used the Strong test for selecting programmers in the absence of programmer profiles by making a judgment that a programmer is ‘like’ a mathema- tician, engineer, writer, or what have you. Since the basis for these judgments is pure speculation, such selection procedures could have been equaled by throwing dice. Throwing dice, however, does not have the right sound to it. A personnel manager can say, “‘We use the Strong Vocational Interest Blank to help us select programmers.” This will cer- tainly impress his manager more than saying, “‘We throw dice to help us select programmers.” Now, however, we have a profile for programmers (Perry and Cannon, 1966)—and if personnel managers actually use it as intended, something better than dice-throwing might be accomplished, though there are many reasons for doubting it. For instance, which type of programmer are we talking about? Or will we have separate profiles for systems programmer, applications programmer, product test programmer, maintenance pro- grammer, and so forth? Even assuming that the profiles are available with sufficient resolution of job descriptions, do they really reflect what we want? After all, these profiles are obtained by testing people already in the profession, not the people we would necessarily want to be in it if we knew what we wanted. For old, established, and stable professions, it may be valid to assume that people in the profession are, by and large, the ones who should be in it—even though they may have been steered there by the Strong Vocational Interest Blank, completing the cycle of a self-fulfilling prophecy. But surely we are not in that advanced state of knowledge about programming as yet. There is, on the contrary, reason to believe that employers, at least, are not at all satisfied with the average pro-
Personality Factors 155 grammer they employ. Why then should this group be used as a tem- plate into which all programming applicants must fit? One other point deserves mention in this regard—the question of “cheating.” Essentially all psychological tests—certainly including all the personality tests—assume that the psychologists who made the tests are smarter than the people who take them. Indeed, if we were to take a personality inventory of people who are attracted to psychological test- ing as a profession, we should probably find that these peaple generally hold themselves to be smarter than other people. Perhaps it could not be otherwise, for how would they get evidence to the contrary? But just because they believe they are smarter does not mean that they are smarter. In a way, a personality test is an intelligence test—a matching of wits with the person who made the test. Suppose, for example, an applicant for a programming job takes a test where he is asked to agree or disagree with the statement, ‘When | concentrate too hard on a problem, | often get a headache, which keeps me from working.” Anyone who wouid be stupid enough to answer ‘‘agree” to that statement probably isn’t smart enough to be much of a programmer. As we know, applicants for pro- gramming jobs are likely to be a rather clever bunch, so we can assume that a great deal of “cheating” will take place if they are given such tests. But that should not worry us, for if they cheat successfully, they are probably going to have a number of the critical personality traits we desire—adaptability to sense the direction of the test, ability to tolerate the stress of being examined by someone they don’t know under as- sumptions they cannot challenge, assertiveness to do something about it, and sense of humor enough to enjoy the challenge. Psychological testers, of course, will deny the possibility of such cheating, or at least pooh-pooh its importance or frequency. But cheating is practiced among programmers. One large company had hired a psy- chological consulting firm to derive a personality profile for them to use in the hiring of programmers. As usual, the profile was to be based on a group of people who already were programmers in this company—with the added feature that only the acknowledged “best” programmers in the company were to be used (although it is not at all clear that we want a programming staff composed entirely of ‘‘best’’ programmers). The programmers to be tested for creating the standard were chosen by the criterion of having been selected to attend a company-wide pro- grammers’ meeting. A few hours were set aside for the administration of the tests, but when the psychologist arrived at the testing room, he discovered that there were 60 people to be tested instead of the 30 he had anticipated. He did not have enough test blanks, but since this
156 Programming as an Individual Activity particular personality inventory was in two parts, the problem was solved by having half do part A first and half do part B. At the conclusion of the first half of the session, the papers were exchanged and the psychologist addressed the group with the standard instructions, terminat- ing with the perfunctory question, “Are there any questions?” To his utter astonishment—since the group had already completed one-half of the test, one of the programmers raised his hand. When the psychologist regained his composure enough to call on the questioner, he got the perfectly straight-faced query, “Are we supposed to use the same personality on this half as we used on the other?” The psychologist, who did not seem to be as adaptable in the face of stress as the average programmer, turned red in the face, then sputtered for a while before he managed to say in his most kindergarten-con- descending tone, “You’re supposed to answer the questions honestly, to the best of your ability.” “What kind of fools do you take us for?” was the reply from another of the programmers, at which point the whole room broke up in waves of conspiratorial laughter. PERSONALITY TESTING OF PROGRAMMERS With all of these cautions about personality tests in mind, we may look at some of the results of personality testing of programmers. David B. Mayer (1968) has provided a useful survey of some of the results with the Strong Vocational Interest Blank and other testing instruments, and the reader with a stronger interest in the Strong Interest Blank than we shall satisfy should look there for further illumination. Mayer first ap- propriately cautions that the author of this instrument does not claim that it predicts performances on the job. What it does is to elicit information regarding the person’s interests. The relationship of a person’s interests to the kind of job he does is left to the user to decide. Mayer points out that the Strong Blank did show certain differences between the programmers tested and the general population, and he offered a few selected examples of the type likely to catch the public interest. For instance, more programmers “like conservative people” and fewer “like progressive people” than do people in the general population. After arousing the reader’s interest with such titillating examples, Mayer lowers the boom. He asks, “Can we look at individual items in the SVIB to see if these indicate anything in regard to the general interest pat- tern that should be the pattern of a successful programmer? The answer to this is a decided NO.”
Personality Factors 157 Why is Mayer so emphatic in rejecting this kind of game with individual Strong items? Because, in the first place, the instrument was only in- tended to be used with an analysis of the entire pattern of 400 responses. To make such an analysis, one would have to use a scoring key worked out on the basis of a large sample, such as that developed by Perry (1966). Perry’s scoring key for programmers is not available for all users of the Strong Vocational Interest Blank, but as of 1968, at least, a survey of organizations revealed that none of them were using Strong, the only personality test of any kind for which a programmer scoring then existed. Other tests in the personality and interest area which were in slight use at the time Mayer made his survey were the Thurstone Temperament Schedule, the Activity Vector Analysis, and the Kuder Preference Test, although only about 10 or 15 out of 282 organizations were using any such tests. In view of our reservations on the use of these tests in programming, it seems that many companies have made a wise decision in waiting for much further work before plunging into personality testing of their programmer applicants. Even given the existence of valid testing instruments for testing in- terest and personality, the personnel manager would be faced with the nontrivial problem of which tests to use for which purposes and in what order—and what to do with the results once he had them. Since tests cost money to administer and to have scored, the burden of proof of usefulness rests on those who propose that a test be used in preference to simpler, more intuitive methods. Mayer refers to an “X-factor which can be extracted from simple interviews, and which he suspects is related to aptitude. My own interviewing experience tends to weight my ‘X- factor’ more to personality items, as we have discussed. To be worth its cost, a psychological testing instrument is going to have to do better than X-factors—demonstrably better. Along this line, it may be appropriate to cite the classical, though perhaps apocryphal, story of one of the largest efforts ever made to select people on the basis of psychological tests. During World War Il, the United States Army was faced with the problem of fighting on widely different fronts, and they soon discovered that some men per- formed very poorly in tropical areas and others performed very poorly in wintry climes. In an effort to preselect soldiers for one theater of opera- tion or another, a large study was commissioned, and hundreds of questions were tested for correlation with battlefield performance. At the end of this effort—which coincided with the end of the war and was thus too late to be effective—only one question turned out to have Significant correlation with climatic influence on fighting behavior. And what was that question? Simply this: ‘“‘Which do you like better, hot weather or cold?” Has anyone ever thought of asking applicants whether or not they /ike programming?
158 Programming as an Individual Activity SUMMARY Because of the complex nature of the programming task, the pro- grammer’s personality—his individuality and identity—are far more im- portant factors in his success than is usually recognized. Nevertheless, personality tests have not been used successfully for selecting program- mers who will become good programmers. Part of the failure may be attributed to the inadequacies of the tests, part to the inadequacies of our understanding of programming itself, and part to the inadequacy of our knowledge of which personality factors play what role in which part of the programming process. All the same, there seems to be evidence that critical personality factors can be isolated and associated with particular programming tasks—at least in the sense of their possession rendering one incapable of per- forming that task well. Consequently, attention to the subject of person- ality should make substantial contributions to increased programmer performance—whether that attention is paid by a psychological re- searcher, a manager, or the programmer himself. QUESTIONS For Managers
- Have you ever had an employee display a sudden change in person- ality? What did you do about it, and what would you do differently today in the same situation?
- What personality traits do you look for in selecting your programmers? What personality traits do you regard as favorable when evaluating your programmers? Are they the same traits, and if not, why not?
- Does your organization use personality tests in selecting programmers? If so, are the people (including yourself) who use these tests properly trained in their interpretation? Are you aware of any validation of the effectiveness of these tests for selecting programmers? Have you at- tempted any validation within your organization, or for your own in- formation? For Programmers
- What single personality factor do you feel is most useful to you as a programmer? Do you feel that this factor was important to your em- ployer when he hired you for the job?
- What single personality factor do you feel is most harmful to you in performing your job as a programmer? Was this factor considered
Personality Factors 159 when you were hired? What are you doing to diminish the effect this factor has on your performance? 3. Ask some of your coworkers to answer Questions 1 and 2 for you. Do they give the same answers as you gave for yourself, or did you learn something about yourself as seen by your fellow workers? What do you intend to do about it? BIBLIOGRAPHY Mayer, David B., and A. W. Stalnaker, Use of Psychological Tests in the Selection of Computer Personnel, SHARE/GUIDE Presentation, October, 1968. This survey was adapted from a tutorial presentation given at the Fifth Annual Conference on Computer Personnel Research sponsored by the ACM special inter- est group in personnel research—SIG/CPR. The paper gives a good review of the work of that group since its founding in 1962, and has a good bibliography. Perry, D. K., and W. M. Cannon, A Vocational Interest Scale for Computer Pro- grammers—Final Report, Proceedings of the Fourth Annual Computer Personnel Research Conference, Association for Computing Machinery, New York, 1966, pp. 61-82. Cronbach, L. J., Essentials of Psychological Testing, 3rd ed., New York, Harper, 1970. A serious review of testing. Wernick, Robert, They’ve Got Your Number, New York, Norton, 1956. A nonserious, and therefore very serious, review of testing. Cronbach, Lee J., and Goldine C. Gleser, Psychological Tests and Personnel De- cisions, 2nd ed., Urbana, University of Illinois Press, 1965. Even given the correct application and analysis of a psychological test, the man- ager is faced with making a personnel decision which is not uniquely determined by the test outcome. Or, alternatively, he must decide which tests to give, and whether to test at all. These are not easy decisions, and there are no magic answers, but this book takes a hard, and often mathematical, look at some of the problems. Hall, C. S., and G. Lindzey, Theories of Personality, 2nd ed., New York, Wiley, 1970. There are rather many theories of personality, each of which, no doubt, contains more than a grain of truth and more than a gram of insights for the programmer and programming manager. Hall and Lindzey give fair descriptions and critical analyses of twelve of the most prominent personality theories, and their book seems a good place to start exploring this field for the nonpsychologist. White, R. H., Lives in Progress: A study of the Natural Growth of Personality. 2nd ed., New York, Holt, Rinehart and Winston, 1966. Much of the work on the development of personality has concentrated on the growing child, which is not much use to us until the time comes when we start recruiting child programmers. White, however, is interested in the development of personality in adults. Since he picks up his cases starting about at college grad- uation—the time when many programmers are taking their first jobs—this book is of more than average interest to programming managers. White, R. W., The Abnormal Personality, 3rd ed., New York, Ronald, 1964.
160 Programming as an Individual Activity To discourage programming managers from being so quick to label as ‘‘crazy” people whose personalities they do not understand, White has written this careful textbook, giving a number of cases of people outside the “normal” range of per- sonalities. Books such as these, as opposed to overpopularized accounts of man- agement “‘psychology,” are needed to subdue the instant psychotherapy movement.
Silver Anniversary Notes xx Comments on Chapter 8: Personality Factors Were | writing The Psychology of Computer Programming from scratch today, this chapter would change the most, for this is where | have learned the most in the past twenty-five years. First of all, Isabel Briggs Myers published her Myers- Briggs Type Indicator (MBTI) in 1980,’ causing me to drop all other personality testing theories as of slight relevance to programming. Then, in 1984, David Keirsey and Marilyn Bates published their related theory of temperaments,? which, like the MBTI, deals with “normal” personality differences. | and others have since explored this approach to personality in the context of the software business.? During the same period, | studied with Virginia Satir, learning about “incongru- ent” personality stances—ways of coping when stress grows beyond the “nor- mal” range. The MBTI and Satir’s theory of coping stances have revolutionized my thinking, training, and consulting in the area of human behavior. In the first edition of this book, | predicted, “. . . attention to the subject of person- ality should make substantial contributions to increased programmer perfor- mance—whether that attention is paid by a psychological researcher, a manager, or the programmer himself’ (p. 158). Even though | knew next to nothing about personality at the time, this turned out to be one of my most successful predictions. 1 Isabel Briggs Myers, Gifts Differing (Palo Alto, Calif.: Consulting Psychologists Press, 1980). The press may be contacted at 577 College Avenue, Palo Alto, CA 94306. 2 David Keirsey and Marilyn Bates, Please Understand Me: Character and Temperament Types, 4th ed. (Del Mar, Calif.: Prometheus Nemesis Book Co., 1984). 3 See, especially, Quality Software Management, Vol. 3, which details the Satir coping stances.
te oe en A peragyg alleen ge Yaw de net binge ’ ter toonwe oly ae canine gi vinese of pape o | tat. 2 teow ine @hee at an Conon, ‘2s my ba ae panne so rion Ae nso Ye ant pay
- 10: abnantantod — Bxstyany — | en sR et Namrozto | i = Veber sfukwog aunt groan ny rnd Yo YRC wi patie 6 ay morn ec) peermaat ever | @iectw af aint vol Jeon gr panes Olvowe terger > eat. “are vor. buriaiidegy aril Sond tedaet lle to tPF asey ove pron 6 ‘ vilendersg ’ 49 lie oP of ert OrHZus 5 oOser (fam) Wisco € 0 nevis? BEST ra eet Qed of sonsveles iigiie to 26 eshoer { itty * dnerenagineh io. yond beisies nent boreddug eote8 nyinaM bas . gore earl made oie’ sooner ytisnoeng Sammon ciiw else nt Oe £ ao viawt erated eri! le earnoo tk nn yitev sete Of ceasing ah a anpnoonl’ tuede Wieerwel pHee cinign tiiw beibute Tybeheq ones et Aon” elt broyed twthg epetie naiw gnhgpD to eysw-—geonsiz yler rexinoiulover eves 2eonste pniqes lo odor auited Dna TEN eT . raivedad mame to sens. rl gnithi@nos Das (Oriel gy ave HO ake dart of nolinetie . °.” bavalbeng tplodd diet? to noitiner| aeheg ronimmgarg eases of “proiicthitnos isitistadua extn wk pitt jeganan & jarorssabl leyipoldruyeg s yd blsq ei netinatts Net Yer ode ghiftton-af near wana | Apuott mers {bet a) Woamir 1 aorta Wega laoes yn marae sone te Wel= a a i ye —— le gf a i ia vied aren? ° soci be i ne 6 ip anne Veta Slee Sod . deed elie PIE SOe ins wr wilt. pene aur aia lede aie ni sh : nN _ EHR As ca Slesterct ae bath an nim alae 7 a bed — nbaete: ay pena: poner wee gal