feature

50 I E E E S O F T WA R E Pu b l i s h e d b y t h e I E E E Co mp u t e r So c i e t y 0 74 0 - 74 5 9 / 10 / $ 2 6 . 0 0 2 0 10 I E E E
As a dictionary defnition, Id say that pair
programming is a technique in which two people
sit down, literally side by side, and write a pro-
gram at the same computer. When Kent Beck
originally coined the term, he described two
programmers working at different levels of ab-
straction.
1
Laurie Williams and Robert Kessler
made this idea more concrete, using the meta-
phor of one programmer being the driver and
the other the navigator.
2
In this metaphor, the
driver controls the keyboard and focuses on the
immediate task of coding, and the navigator acts
as a reviewer, observing and thinking about more
strategic architectural issues.
My own experience as a developer using pair
programming is that it isnt just a technique
where one person programs and the other per-
son watches. Both programmers work closely to-
gether, chatting the whole time, jotting down re-
minders of things to do, and pointing out pieces
of code on the screen. (One of the clichs of pair
programming is that if youre doing it right, your
screen should be covered with greasy fnger-marks
by the end of the day.) Programmers take turns
at the keyboard, usually swapping over with a
phrase like, No, let me show you what I mean.
Jan Chong and Tom Hurlbutt confrmed this
view of successful pair programming after spend-
ing several months on an ethnographic study of
professional developers who use pair program-
ming in their daily work.
3
They found that pro-
grammers tended to work together on the same
facet of a problem almost the whole time and
swap between tactical and architectural levels as
a pair. Similar ethnographic studies by Sallyann
Bryant and her colleagues
4
and Stephan Salinger
and his colleagues further confrmed this.
5
Of course, not all attempts at pair program-
ming have been successfulMatt Stephens and
Doug Rosenberg, for example, reported unfa-
vorably on their experiences.
6
However, what
they described is a caricature of the driver-
navigator metaphor, with one programmer frmly
in control and the other sitting quietly, doing little.
Such misunderstanding shows that we cant take
a claim that developers are pair programming at
face value; they might not be doing what experi-
enced and effective pair programmers actually do.
P
air programming has generated considerable controversy: some developers
are enthusiastic about it, almost evangelical; others are dubious, even hostile.
However, a large factor in this controversy is that programmers label a wide
variety of practices under the pair programming umbrella. Thus, before
our community can sensibly discuss how pair programming works, we frst need to es-
tablish exactly what it is.
Pair programming
isnt always
successful, and
recent studies cast
doubt on the driver-
navigator metaphor.
Four mechanisms
can improve pair
programming
performance.
Stuart Wray, Royal School of Signals
How Pair Programming
Really Works
pr ogr ammi ng
Share your
comments at http://
computingnow.
computer.org/wray.
January/February 2010 I E E E S O F T WA R E 51
This kind of misunderstanding also casts
doubt on the many attempts to assess pair pro-
grammings effectiveness. (Tore Dyb and his
colleagues provide a very nice summary of this
experimental work.
7
) If the subjects of these ex-
periments did different things, can we really com-
pare their results? And if they werent doing what
successful pair programmers do in commercial
practice, can we apply their fndings to commer-
cial development?
In this article, I advance four mechanisms
prompted by my own experience of pairing in
both agile and non-agile development. These
mechanisms explain a large part of what suc-
cessful pair programmers do. Of course, this is
only the beginning: you might have experiences
that confrm or contradict my suggestions. What
have I missed? I hope youll contribute to the dis-
cussion of these issues on the Web site (http://
computingnow.computer.org/wray).
Mechanism 1:
Pair Programming Chat
Around 1980, as computer science undergradu-
ate students at the University of Cambridge, my
friends and I noticed a strange phenomenon that
we called expert programmer theory. When one
of us had trouble getting our programs to work,
wed describe the nonfunctioning state of our code
to each other over coffee. Quite often, wed real-
ize in a fash what was wrong and how to solve
it. These epiphanies were quite independent of the
other person having any real understanding of our
problemsthe listener often seemed little wiser
about the subject.
Since then, Ive found this phenomenon is well
known to professional developers, and sometimes
described in textbooks and research papers. For
example, Brian Kernighan and Rob Pike recom-
mended explaining problems aloud, even to a
stuffed toy,
8
a practice that John Sturdy called the
rubber-plant effect.
9
Part of pair programmings
effectiveness is presumably due to this effect be-
ing continually triggered: as one programmer gets
stuck, the back-and-forth chat serves to unstick
them in the same way as solo programmers talk-
ing about their problems out loud. However, this
raises the question of whether any type of speak-
ing will help or whether something specifc is
needed.
Research on self-explanation by Michelene
Chi and others throws some light on this ques-
tion. Chi and her colleagues described a study that
tested a control group of students before and after
they received a textbook explanation to read.
10

They tested another group in the same way, but
encouraged the students to explain the textbook
out loud and fll in the gaps for themselves. The
self-explainers learned signifcantly more than the
control group, and those who explained the most
improved the most. The researchers also prompted
the students for their explanations; they werent just
left to their own devices. In particular, they were
prompted for further clarifcation by the experi-
menter if what they stated was vague.
10
This brings me back to an often-neglected as-
pect of the expert programmer theory. When we
coined that term, we noticed that although real un-
derstanding wasnt necessary on the listeners part,
a belief that the listener really was an expert seemed
to signifcantly improve the outcome (hence our
choice of name).
But why would believing that you were talk-
ing to experts make any difference when they
didnt need to understand your explanation? Re-
cent work by Rod Roscoe and Chi showed that
prompting questions seems to be the key.
11
In their
study, one student (the tutor) explained material to
another student (the tutee). As expected, the tutor
actually learned more than the tutee, but the ques-
tions the tutee asked made a dramatic difference in
the quality of the tutors explanations. Most ques-
tions were shallow, and could be satisfed by mere
repetition of facts, but some questions were deep
and often prompted deep answers that included
novel inferences or self-monitoring statements.
So perhaps this is how expert programmer the-
ory really works: an expert is more likely to ask a
deep question, which prompts the novel inference
from the stuck programmer. It also seems possible
that merely thinking that youre talking to an ex-
pertor pretendingwill help the stuck program-
mer produce the sort of deep questions that experts
have asked them in the past.
As an explanation for expert programmer the-
ory, this is almost satisfactory, but is student learn-
ing a good analogy for what happens to stuck
programmers? After all, the students in these ex-
periments had to master basic science, and their ex-
planations helped them work out what they didnt
understand. Stuck programmers must already have
all the information somehow hidden in their heads
and then realize the answer in a moment of epiph-
any. Hows that possible?
Its widely accepted that cognitive abilities are
divided into a variety of largely separate mental
modules, each dealing with a different ability
such as intuitive grasp of small numbers, predict-
ing other peoples actions, facial recognition, and
so on. Less well known is the role of the language
An expert is
more likely
to ask a deep
question, which
prompts the
novel inference
from the stuck
programmer.
52 I E E E S O F T WA R E www. c o mp u t e r . o r g / s o f t wa r e
module in integrating other modules knowledge.
Experiments by Linda Hermer-Vazquez and her
colleagues on integrating knowledge about ge-
ometry and color
12
and by Ashley Newton and
Jill de Villiers on false-belief reasoning
13
showed
that adults perform as poorly as young children
when their linguistic abilities are occupied with
a verbal shadowing task. The language mod-
ule seems crucial to combining knowledge from
other modules.
This isnt to say that we integrate the outputs
of several mental modules by talking to ourselves.
Rather, Peter Carruthers suggested that because
speech is uniquely both an input and output brain
medium, the language module is the only one
with a strong connection to all the other mod-
ules.
14
The mechanisms underlying the logical
form of language might thus be redeployed at a
level beneath conscious awareness to integrate in-
formation from other modules. The logical form
must be able to represent objects with properties
derived from several modules because this is the
basis for noun-phrases in speech.
As programmers, we clearly use visual imagi-
nation to help design and debug our programs
(although the diagrams we use bear little rela-
tion to our programs texts). This visual informa-
tion can be spread across several mental modules,
and the other information we require to under-
stand our programs can be in yet other modules.
For example, it seems that our understanding of
object-oriented (OO) programs is supported by
the folk psychology module that supplies intu-
itions about other peoples actions. (We think of
objects as having intentions, wanting to do things,
and sending each other messages.) We therefore
need to integrate information from separate mod-
ules when thinking about our programs. Why
cant we always integrate it straightaway?
Carruthers suggested that we must rely on the
language module posing the right question and
that the other modules dont usually present in-
formation spontaneously. However, when we
hear the right question, our brains make the nec-
essary information available, and the language
module can then perform rudimentary inference
and draw the obvious conclusions. Carruthers
suggested that the key is posing a question thats
both relevant and fruitful.
14
The right question
draws forth the crucial knowledge, and in a mo-
ment of epiphany, the answer becomes obvious
This frst mechanism would therefore lead us
to predict that programmers who chat about their
programs more should be more productive and
that those who pose occasional deep questions for
each other should be most productive of all.
Mechanism 2: Pair
Programmers Notice More Details
Research on change blindness and inattentional
blindness illustrates something that stage magi-
cians have known for a long time: if we dont know
what to look for, we can stare right at it and still
miss it. What we notice depends on what we ex-
pect to see and what we unconsciously consider
salient. So, although successful pair programmers
will concentrate mostly on the same things, they
might notice different things.
Research on change blindness shows that peo-
ple are remarkably poor at detecting changes, not
only in 2D images under laboratory conditions but
in real-life situations such as noticing the substitu-
tion of one person with another.
15
It appears that
people remember something they saw as belonging
to a particular mental category, then fail to notice
substitution by another member of that category.
A large portion of experts profciency is probably
in their more detailed and extensive array of men-
tal categories in their particular felds.
16
Research
on inattentional blindness has similarly shown that
when our attention is focused on a particular task,
we can miss something that would otherwise be
so obvious that it would just pop out. For exam-
ple, it might seem unlikely that people would miss
a woman in a gorilla suit walking into the shot in
a video, but thats what half the subjects did in a
study by Daniel Simons and Christopher Chabris.
17

(Theyd been instructed to pay close attention to an-
other aspect of the video.)
So, two people programming together wont
have the same prior knowledge or categorization:
one will presumably spot some things faster and
the other different things faster. Where their rate of
working is limited by the rate they can fnd things
by just looking, two heads must be better than one.
And in fact, one of the earliest observations that
people make when they start to pair program is that
the person who isnt typing code always picks up ty-
pos quicker: Oh, youve left out the comma here.
Of course, the compiler would pick up such
small slips easily, so in this case the early catch
isnt very important. However, its crucial to catch
problems early when the slip is more subtlefor
example, if the code is syntactically correct but se-
mantically wrong, or where theres a fault in the
design itself. Such slips can easily cause hours of
problems at a later date. The ability to catch mis-
takes early in an online code review is only one
beneft of two pairs of eyes: perhaps even more im-
portant is looking at old code with a fresh eye and
What we
notice depends
on what we
expect to see
and what we
unconsciously
consider
salient.
January/February 2010 I E E E S O F T WA R E 53
a different set of expectations, reading what it re-
ally says, not what it ought to say.
This second mechanism also partially explains
the phenomenon of pair fatigue, which Ive noticed
in myself and others. When two programmers pair
together, the things they notice and fail to notice
become more similar. Eventually, the beneft from
two pairs of eyes becomes negligible. Beck sug-
gested that pairs should rotate at frequent intervals,
perhaps once or twice a day.
1
Arlo Belshee found
that in a jelled team, rotating after two hours was
optimal.
18
Some pair programmers regard rota-
tion as an optional part of the practice, and on a
small team, or with few programmers willing to
pair, there might be little alternative. However,
pair fatigue means theyll ultimately be much less
productive.
On the other hand, because a great deal of ex-
pert knowledge is probably in the form of catego-
ries in long-term memory, a novice might be un-
able to distinguish between events experienced at
different times. Experts really can see things that
novices cant. We could therefore predict that this
second mechanism will bring the maximum ben-
eft to novice pairs; indeed, the most extensive ex-
periment with novice pairs and experts found that
novice pairs benefted the most.
19
Mechanism 3:
Fighting Poor Practices
As programmers, we dont always use the best
practices. An advantage of pair programming is
said to be pair pressure, the feeling of not wanting
to let your partner down.
20
But why is this nec-
essary? Why do we persist in poor programming
practices when we know theyre poor? Is there
something special about programming that makes
it more diffcult to do the right thing? It appears
that there is.
Lets look at a particular example of worst
practice: the code-and-fx style of programming
most often used by novices (and sadly, often used
by more experienced programmers). Programmers
write some code that they hope will do a particu-
lar thing and then run it to see what happens. If
it appears to work, they press on with other code,
without systematically searching for faws. When
it fails, which is often the case, they tinker with the
code haphazardly until it appears to work. Why
is this style of programming so compelling and so
easy to discover independently?
Traditional behavioral psychology offers a very
plausible explanation, although more modern
work on the neuroscience of learning and addic-
tion also points in the same direction. One form
of learning explored by behavioral psychologists,
called operant conditioning, involves learning to
perform some action spontaneously. This is the
way that animals learn to perform tricks in circus
acts or domestic dogs are taught obedience. An
animal has a variety of behaviors that it engages
in occasionally, and with operant conditioning, we
can supply the animal with a reward after we ob-
serve it doing what we want (which reinforces the
behavior). As this reinforcement process continues,
the desired behavior becomes more likely to hap-
pen spontaneously, even when no reward is given.
Of course, if the rewards stop entirely, the be-
havior diminishes and fnally ceases, a process
known as extinction (which happens quite slowly).
If we supply a further reinforcement before the be-
havior has entirely ceased, we can easily restore it
to full strength. In fact, learning happens quickest
if the reward pattern is unpredictable, with a so-
called variable ratio (VR) schedule of reinforce-
ment. Henry Gleitman and his colleagues explain:
In a VR schedule, there is no way for the ani-
mal to know which of its responses will bring
the next reward. Perhaps one response will
do the trick, or perhaps it will take a hundred
more. This uncertainty helps explain why
VR schedules produce such high levels of
responding in humans and other creatures.
Although this is easily demonstrated in
the laboratory, more persuasive evidence
comes from any gambling casino. There, slot
machines pay off on a VR schedule, with the
reinforcement schedule adjusted so that the
responses occur at a very high rate, ensuring
that the casino will be lucrative for its owners
and not for its patrons.
21
This learning is unconscious: we need not realize
that its happening to us, and in the case of the ca-
sino, a machine instead of a real person is condi-
tioning the slot-machine patrons. In our habitual
patterns of software development, we too can be
conditioned by our machines. This is the special
property of interactive programming that makes
it diffcult to do the right thing. With code and
fx, we tinker haphazardly with our programs, ef-
fectively putting a coin into the slot machine each
time we run our code. Slot machines are known
as the most addictive form of gambling, and the
similarly unpredictable rewards from code-and-
fx programming mean that it could be equally
addictive.
How can we resist this addiction? Perhaps
we can try to just say no and choose a differ-
54 I E E E S O F T WA R E www. c o mp u t e r . o r g / s o f t wa r e
ent development pattern. Some development pro-
cesses attempt to remove temptation by being less
interactive. Edsger Dijkstra suggested that stu-
dents shouldnt be allowed near a computer un-
til theyd learned to write programs away from
one.
22
Such ideas might have once had merit, but
it seems foolish to turn our backs on the orders-of-
magnitude increase in computer power available
to us.
Pair programmers might be less susceptible to
poor practices because they can promise to write
code in a particular way and ensure that each
others promises are kept. The prevalence of two-
people working in jobs where human fallibility is
a serious problem should lead us to seriously con-
sider that pair pressure might be the solution for
us, too. However, you can only keep a promise if
you made one in the frst place. We should there-
fore expect that to beneft from the third mecha-
nism, programmers must agree in advance how
theyre going to write and test their code.
Mechanism 4: Sharing
and Judging Expertise
Even within a single development team, conven-
tional wisdom says that some programmers are
up to 10 times more productive than others.
23

Certainly we see a wide range of expertise, but
how confdent can we be in saying who contrib-
utes most to overall productivity? Assigning credit
for success is diffcult in team activities because
there are so many variables.
In some felds, its easy to recognize experts
because individual contributions are simple to
measure. Chess players have numerical rankings;
golfers have handicaps. These are good predic-
tors of their likely success against other players.
But in team activities, so many factors contribute
to success or failure that we simply cant under-
stand the causal relationships without a detailed
scientifc investigation, so we usually select one or
two arbitrary factors to simplify the analysis.
24
In
software development, lines of code written per
day often gets elevated above all others, simply
because its easy to measure. But selecting such
arbitrary factors tends to promote star players
who demonstrate those qualities but dont signif-
cantly contribute to the teams success.
Unfortunately, more detailed scientifc analysis
is seldom practical. So how can we assign individ-
ual credit (or blame) for team performance? Paul
Graham said that when an expert programmer
works alongside another programmer on the same
problem, the expert can judge the other program-
mers skill. But thats the only way: he or she cant
tell just by meeting them. I cant tell, even now, he
wrote. You also cant tell from their rsums.
25
This is my experience, too: it isnt enough to
talk with someone about programming; you have
to work on a problem with them to gauge their ex-
pertise. A weak version of this technique is stan-
dard practice in programming interviews. After
the preliminary discussion centered on the appli-
cants rsum, the interview proceeds to a series of
successively more diffcult programming exercises
that the applicant has to talk through at a white-
board. Im frequently surprised by how a very
plausible-sounding candidate, when challenged
in this way, completely fails to produce even the
most basic evidence of the knowledge that he or
she earlier claimed.
Sadly, these poor candidates seem blissfully
unaware of their own lack of expertise. Theyre
so bad that they dont realize how bad they are,
probably because, in the words of Justin Kruger
and David Dunning, the same knowledge that
underlies the ability to produce correct judgments
is also the knowledge that underlies the ability to
recognize correct judgment.
26
In a feld where
expertise is hard to measure, this is a serious prob-
lem, because as Kruger and Dunning observed,
the less competent are often more confdent of
their own ability than their more expert peers.
The most competent, on the other hand, suffer
from the opposite problem, the false consensus ef-
fect, in which they believe that their own abilities
are typical. This happens for the same reason: its
hard to accurately assess others competence, so
the most competent have no reason to believe that
theyre extraordinaryunless they work closely
with another programmer on the same problem.
Most programmers work on problems on their
own, so no one knows how good (or bad) they re-
ally are. But with pair programming, people con-
tinually work together. Because they keep swapping
pairs, everyone on the team learns whos the most
expert at particular things. From this comparison,
they also realize their own level of expertise. We
should therefore expect more accurate estimates
of time and diffculty by a pair programming team
than from a solo programming team. From my ex-
perience, this does appear to be the case.
W
ere no longer in the frst fush of
pair programming, yet the gulf be-
tween enthusiasts and critics seems
as wide as ever. Experimental evidence has been
equivocal. How can we advance our understand-
ing? I believe the mechanisms I describe here are
Some
programmers
are up to
10 times more
productive
than others.
January/February 2010 I E E E S O F T WA R E 55
among the fundamental properties shared by all
instances of successful pair programming, but
other mechanisms are important, too: for ex-
ample, team jelling appears to have a signifcant
effect. What other mechanisms are signifcant?
Although I believe that pairing works the same
in agile and non-agile settings, this has yet to
be established. In addition, there might be anti-
mechanisms: poor practices that lead to unsuc-
cessful pair programming and that arent merely
the absence of the benefcial mechanisms. To in-
vestigate all of these, we could solicit suggestions
from working developers; ethnographic research-
ers could reexamine their records for evidence for
or against the mechanisms.
We also need some form of objective check-
list to compare results across experiments, so that
experimenters can agree how much a particular
programming team uses a particular mechanism.
With such a checklist, we could then reexamine
the experiments that Dyb described
7
and attempt
to establish the extent to which the teams used cer-
tain mechanisms. However, such post hoc analysis
could still give equivocal results. To clearly estab-
lish the mechanisms impact, we must design new
experiments that properly control for them.
Perhaps you have some other questionsor
even some answersin mind right now. If so,
I invite you to share your comments on the Web
site (http://computingnow.computer.org/wray). In
any case, I hope that thinking about these mecha-
nisms will help you apply pair programming more
effectively.
References
1. K. Beck, Extreme Programming Explained: Embrace
Change, 1st ed., Addison-Wesley, 2000.
2. L. Williams and R. Kessler, Pair Programming Illumi-
nated, Addison-Wesley, 2003.
3. J. Chong and T. Hurlbutt, The Social Dynamics of
Pair Programming, Proc. 29th Intl Conf. Software
Eng. (ICSE 07), IEEE CS Press, 2007, pp. 354363.
4. S. Bryant, P. Romero, and B. du Boulay, Pair Program-
ming and the Mysterious Role of the Navigator, Intl
J. Human-Computer Studies, vol. 66, no. 7, 2008, pp.
519529.
5. S. Salinger, L. Plonka, and L. Prechelt, A Coding
Scheme Development Methodology Using Grounded
Theory for Qualitative Analysis of Pair Programming,
Proc. 19th Ann. Workshop Psychology of Program-
ming Interest Group (PPIG 07), Psychology of Pro-
gramming Interest Group, 2007, pp. 144157; www.
ppig.org/papers/19th-Salinger.pdf.
6. M. Stephens and D. Rosenberg, Extreme Programming
Refactored: The Case against XP, Apress, 2003.
7. T. Dyb et al., Are Two Heads Better than One? On
the Effectiveness of Pair Programming, IEEE Soft-
ware, vol. 24, no. 6, 2007, pp. 1215.
8. B. Kernighan and R. Pike, The Practice of Program-
ming, Addison-Wesley, 1999.
9. J. Sturdy, Sidebrain: A Sidekick for the Programmers
Brain, Proc. 17th Ann. Workshop Psychology of
Programming Interest Group (PPIG 07), Psychology
of Programming Interest Group, 2005, pp. 215226;
www.ppig.org/papers/17th-sturdy.pdf.
10. M. Chi et al., Eliciting Self-Explanations Improves
Understanding Cognitive Science, vol. 18, no. 3, 1994,
pp. 439477.
11. R. Roscoe and M. Chi, The Infuence of the Tutee in
Learning by Peer Tutoring, Presented at 26th Ann.
Conf. Cognitive Science Soc., 2004; www.cogsci.
northwestern.edu/cogsci2004/papers/paper278.pdf.
12. L. Hermer-Vazquez, E.S. Spelke, and A.S. Katsnelson,
Sources of Flexibility in Human Cognition: Dual-Task
Studies of Space and Language, Cognitive Psychology,
vol. 39, no. 1, 1999, pp. 336.
13. A. Newton and J. de Villiers, Thinking While Talking:
Adults Fail False-Belief Reasoning, Psychological Sci-
ence, vol. 18, no. 7, 2007, pp. 574579.
14. P. Carruthers, The Cognitive Functions of Language,
Behavioral and Brain Sciences, vol. 25, no. 6, 2002, pp.
657726.
15. D. Simons and D. Levin, Failure to Detect Changes to
People During Real-World Interaction, Psychonomic
Bull. and Rev., vol. 5, no. 4, 1998, pp. 644649.
16. N. Charness et al., The Cambridge Handbook of
Expertise and Expert Performance, Cambridge Univ.
Press, 2006.
17. D.J. Simons and C.F. Chabris, Gorillas in Our Midst:
Sustained Inattentional Blindness for Dynamic Events,
Perception, vol. 28, no. 9, 1999, pp. 10591074.
18. A. Belshee, Promiscuous Pairing and Beginners Mind:
Embrace Inexperience, Proc. Agile Development Conf.
(AGILE 05), IEEE CS Press, 2005, pp. 125131.
19. E. Arishholm et al., Evaluating Pair Programming
with Respect to System Complexity and Programmer
Expertise, IEEE Trans. Software Eng., vol. 33, no. 2,
2007, pp. 6586.
20. L. Williams and R. Kessler, The Effects of Pair-
Pressure and Pair-Learning on Software Engineering
Education, Proc. 13th Ann. Conf. Software Eng.
Education and Training (CSEE&T 00), IEEE CS Press,
2000, pp. 5965.
21. H. Gleitman, A.J. Fridlund, and D. Reisberg, Psychol-
ogy, 6th ed., W.W. Norton & Co., 2004.
22. E. Dijkstra, On the Cruelty of Really Reaching Com-
puting Science, 1988; www.cs.utexas.edu/users/EWD/
ewd10xx/EWD1036.PDF.
23. R. Glass, Facts and Fallacies of Software Engineering,
Addison-Wesley, 2003.
24. M. Gladwell, Game Theory, The New Yorker,
29 May 2006; www.newyorker.com/archive/2006/
05/29/060529crbo_books1.
25. P. Graham, Great Hackers, 2004; www.paulgraham.
com/gh.html.
26. J. Kruger and D. Dunning, Unskilled and Unaware
of It: How Diffculties in Recognizing Ones Own
Incompetence Lead to Infated Self-Assessments, J.
Personality and Social Psychology, vol. 77, no. 6, 1999,
pp. 11211134.
About the Author
Stuart Wray is a senior lecturer at the Royal School of Signals. His research interests
include the psychology of programming, computer security, and functional programming.
Wray has a PhD in computer science from the University of Cambridge. Since then, hes
worked in research at the Olivetti Research Laboratory and the University of Cambridge
Computer Laboratory, and in product development at Virata, Marconi, and BAE Systems.
Contact him at [email protected].
Selected CS articles and columns are also available
for free at http://ComputingNow.computer.org