Programmers are known to be proud of their work. Some developers even feel that writing elegant code is a form of art, and thus they call themselves “software craftsmen”. I am sure that the desire to perform outstanding work is normal in any profession, but in the case of software development the programmers are constantly exposed to pieces of code written by their colleagues. If everyone can see your code, you naturally feel the need to write well.
So now I ask you: Are you a good programmer? Are you above average as a software developer? Perhaps you are in the top 20%, or even in the top 10%?
I’m almost sure that your answer is that you are above average. Most programmers feel like that. But, of course, if most programmers think they are above average, many of them are wrong…
Illusory Superiority
This general phenomenon of feeling “above average” is called Illusory Superiority, and it has been studied by social psychologists. Here is a definition from Wikipedia:
“Illusory superiority is a cognitive bias that causes people to overestimate their positive qualities and abilities and to underestimate their negative qualities, relative to others.”
Here are some concrete examples that were observed by researchers in this field:
“87% of MBA students at Stanford University rated their academic performance as above the median.”
“For driving skill, 93% of the US sample put themselves in the top 50%.”
So MBA students and drivers are just two examples, but the same phenomenon has been observed in diverse environments. If you have experience with software development, you probably agree that programmers are no exception.
But what is wrong about this Illusory Superiority? Self-esteem is certainly a good think. A good professional should have confidence in his abilities to handle his tasks. No one would like to work with a person who is insecure.
The problem with Illusory Superiority is when someone underestimates the capacity of others. This is particularly dangerous when we expect people to work as a team, but someone in this team believes he is much more skilled than his colleagues.
Respect and Recognition
What is the cure for this illusory feeling of superiority? How can we make the programmers in a team respect each other, and even admire their peers because of the recognition of their experience and skills?
I believe that the key for respect and recognition is joint work, as close as possible. And in this case the Agile methods provide more opportunities for cooperation than traditional approaches.
Perhaps the closest form of joint work is Pair Programming. In this case, software developers work in pairs, writing the code together. Several studies have demonstrated that Pair Programming has a positive impact in the quality of systems. But in my opinion another important benefit is the ability to strengthen the bonds among programmers working as a team.
In the case of Scrum, the daily stand-up meetings are an opportunity for each person to learn about the progress of the other members of the team. Even if each programmer is working alone on his individual tasks, he is able to follow the implementation of the system as a whole. In other words, we could say that Scrum promotes a holistic view, allowing each team member to appreciate the challenges being faced by the others.
Real Superiority
But what happens when you are really superior? How should you behave when you are the most experienced developer in a team, or when you are the only one with particular skills? What happens when in your team there are programmers writing poor code?
I believe that when you are the most experienced developer in a team, this should give you a special kind of responsibility. Or, as in the famous quote from Spider-Man: “With great power comes great responsibility”.
In a working environment in which there is real cooperation between team members, your outstanding capacity will be soon recognized and respected. Then you can assume a natural role of leadership, at least in the areas in which you have special skills. Assuming this technical leadership role means:
- Teaching: If you are the only one with a particular skill, teach others.
- Sharing: If you are the most experienced, share your knowledge.
- Reviewing: If other programmers are writing poorly, review their work.
- Helping: If you can boost productivity, help people to handle their tasks.
But you must always remember that, even if you are “superior”, you can always learn from others. As it’s written in the ancient Jewish book “Ethics of the Fathers”:
“Who is wise? One who learns from every man.”
In this spirit, I will be happy to learn your opinion in the comments below. Thanks!
Effective Software Design 
Interesting.
Many programmers believe they are smarter than the average person. But this can lead to a situation of pride and come to believe that one is more than it really is.
But the truth is that our ability to properly apply knowledge and knowledge is quite limited.
Almost always people in our environment in certain areas are superior to us.
And that’s the beauty and the importance of teamwork.
I Agree, Leo, the basic principle of teamwork is that each one has something to contribute!
During the time that my primary profession was programming, I was quite convinced that I am a really good programmer, certainly above average. I would like to think that I was of the sharing type. But I have learned the hard way that some of the practices I used achieved quite the oposite; or, in other words, creating a situation where others would rely on me for information.
Having focused on other practices as a main occupation: project and product management, architecture, and more, has taught me that all-in-all I was average at most in programming, as I had the opportunity to really learn from others’ code.
The point is, that in a development team it is highly recommended to try out various roles at various times – most notably to switch between testing and programming. By testing I mean all types of tests: unit, system, integration, performance, usability – whatever you can get your hands on.
It will teach you to appreciate your own coding standards – as well as your peers’
Great point, Ilan! I agree that people can learn a lot by switching roles, but unfortunately many developers prefer to specialize on a relatively small set of skills.
Hayim — as Robert Heinlein said, “specialization is for insects” 🙂
Kirschilan – “creating a situation where others would rely on me for information” — that’s a really good point. As an IT systems consultant since 1972, I have always felt that it’s part of my responsibility to “work myself out of a job” — make sure that my client doesn’t become too dependent on me. It’s ethically the right thing to do, and it also ensures that if they continue to use my services, it’s because they value them.
Team software development is a lot more fun than coding alone!
Hayim — some comments on your essay:
“Self-esteem is certainly a good think [sic].” Only if it’s earned! One of
the major problems with child-raising and educational practice over the last 50
years or so is the idea that “self-esteem” is worthwhile and necessary, even if
there’s no basis for it. I would rather see an emphasis on self-respect, based
on a combination of proven character and accomplishment. Spurious (unearned)
“self-esteem” is sometimes indistinguishable from arrogance, and it warps the
individual’s view of his/her relationship to the rest of the world, bending it
toward narcissism.
“A good professional should have confidence in his abilities to handle his
tasks.” But what if that confidence is misplaced? Then it becomes dangerous.
(Of course, by my definition, that person wouldn’t be a “good professional”.)
“I believe that the key for respect and recognition is joint work, as close as
possible.” That’s one approach, but it’s indirect. How about society valuing
demonstrated good character (for respect) and accomplishment (for recognition)?
We used to, but we’ve lost a lot of that.
A variation on “joint work” is peer and manager code review, which can be
extremely effective in promoting and accomplishing a culture of competence and
quality, if the manager running it is him/herself competent. It also promotes
code, knowledge, and skill sharing. It’s basically a “stand-up meeting”, but
deepened and widened to really dig in.
“…your outstanding capacity will be soon recognized and respected” —
ideally, yes. However, in a toxic management situation, your abilities may
engender jealousy and fear. If so, it’s time to sharpen up the old résumé…
“Who is wise? One who learns from every man.” Amen! Almost everyone has
something he/she is passionate about, and typically will have something you can
learn from him/her in that domain.
One thing you didn’t mention is the prevailing standards of performance.
Unfortunately, they’re very low in our field. So someone may be better than
others in the team, but not really be superior. Of course, that person is
probably at least a good candidate for improvement…
Hayim — some comments on your essay:
“Self-esteem is certainly a good think [sic].” Only if it’s earned! One of the major problems with child-raising and educational practice over the last 50 years or so is the idea that “self-esteem” is worthwhile and necessary, even if there’s no basis for it. I would rather see an emphasis on self-respect, based on a combination of proven character and accomplishment. Spurious (unearned) “self-esteem” is sometimes indistinguishable from arrogance, and it warps the individual’s view of his/her relationship to the rest of the world, bending it toward narcissism.
“A good professional should have confidence in his abilities to handle his tasks.” But what if that confidence is misplaced? Then it becomes dangerous. (Of course, by my definition, that person wouldn’t be a “good professional”.)
“I believe that the key for respect and recognition is joint work, as close as possible.” That’s one approach, but it’s indirect. How about society valuing demonstrated good character (for respect) and accomplishment (for recognition)? We used to, but we’ve lost a lot of that.
A variation on “joint work” is peer and manager code review, which can be extremely effective in promoting and accomplishing a culture of competence and quality, if the manager running it is him/herself competent. It also promotes code, knowledge, and skill sharing. It’s basically a “stand-up meeting”, but deepened and widened to really dig in.
“…your outstanding capacity will be soon recognized and respected” — ideally, yes. However, in a toxic management situation, your abilities may engender jealousy and fear. If so, it’s time to sharpen up the old résumé…
“Who is wise? One who learns from every man.” Amen! Almost everyone has something he/she is passionate about, and typically will have something you can learn from him/her in that domain.
One thing you didn’t mention is the prevailing standards of performance. Unfortunately, they’re very low in our field. So someone may be better than others in the team, but not really be superior. Of course, that person is probably at least a good candidate for improvement…
My ‘habib, code alone not fun. Sometimes code alone also not learn and doesn’t grow group practice as team leader or candidate
Pingback: The Psychology of Agile Software Development | Effective Software Design