Less Able Programmer
Less Able ProgrammerThe difference between someone who can step up to the computer and program/design something well without having elaborately diagrammed it, and a hack who paints himself into corners is really one of experience, talent, and motivation to learn.
Everybody thinks that they're an above average driver, which is clearly nonsense. Would it be fair to say, then, that all software engineers believe themselves to be AboveAverageProgrammer?s? In my personal experience, 'above average' would be way too conservative!
"clearly nonsense"? Maybe not the way you think.
Obvious truths aren't always true when you're thinking about knowledge. E.g., if X is Y, you should be able to substitute X for Y without affecting the truth of a statement, but not when you're talking about knowledge. "The morning star is Venus." "The evening star is Venus." Both true, and so "The morning star is the evening star." However, that doesn't make "Julie knows that the morning star is Venus" equivalent to "Julie knows that the evening star is Venus." [Example stolen from Frege, I believe. Yes, from "Über Sinn und Bedeutung" (http://www.gavagai.de/HHP31.htm).]
Less profoundly, it is possible for more than 50% of people to "correctly" think that they're "above average" programmers or drivers, because they each know what "above average" means -- except they don't all agree what it means. Furthermore, people can modify their behavior to optimize what they consider important (and sometimes vice versa, convincing themselves that what they do well or enjoy doing is important:-) so there can easily be a strong positive correlation between a person's ideas about characteristics make someone above average, and that person's own characteristics. 40% of people can correctly consider that they consistently get where they're going faster than average, and are thus above average. 30% more can correctly consider that they drive more safely than average, and are thus above average. Similarly, 20% of programmers can be sure they produce tighter microoptimized code than average, 20% of programmers can be sure they bang out code so fast that they reach stage where they can demo *some* functionality faster than average, 20% of programmers can be sure that their code is more maintainable than average, and 20% of programmers can be sure that they follow the right process more closely than average, and each can be convinced that they're above average for this reason.
I think environment has a lot to do with programming ability. Different environments suit different people and some environments can be bad for all or good for all. I know that I am a LessAbleProgrammer in some environments and an SoftwareGenius in others. -- JonGrover
I second the environment argument. It often depends on what environment/tools/aptitude that the project is using. I've known plenty of people that were much better than myself at designing & creating webpages/C programs/Perl scripts, etc. than I am. However, the really astounding people that are considered LanguageGurus? are also pretty strict specialists. Remember, SpecializationIsForInsects. -- ChadThompson
Assuming that not every team leader has the ability to cherry pick only the finest talent to populate his team, or indeed the ability to jettison those without the 'experience, talent and motivation to learn', maybe ExtremeProgrammingIsDoomed??
Strange, for a long time my belief has been the exact opposite. I see XP as just about the only methodology I know about that can turn a LessAbleProgrammer into a PrettyGoodProgrammerWithGreatHabits, which is about the best you can realistically ask for or expect, and which is much more realistic than the prevailing "strategy" of cherry picking the top 5% of programmers (cf. GrandMasterProgrammer).
I'm not sure about XP as a whole, but PairProgramming is certainly one of the most effective ways of turning a LessAbleProgrammer into a PrettyGoodProgrammerWithGreatHabits, especially in firms whose line on staff training is 'maybe you could read a book or two sometime??'. As an aside, I've been advocating PairProgramming to my lot for some time - but our technical director felt that 'you'd have a hard time convincing [insert name of manager] that half his expensive computer terminals would be unused half the time'.
But you might be able to sell the benefit of only requiring half the number of "terminals" and therefore a lower cost level -- SH.
Let me provide an alternate concurring opinion. I find that TestDrivenDesign coupled with Refactoring and DoTheSimplestThingThatCouldPossiblyWork increase the productivity of the LessAbleProgrammer. These practices encourage decomposition of a problem to its very basic components and allow the programmer to accomplish something. He does not have to focus on "larger" issues such as architecture or class decomposition, rather he starts at the bottom, gets something working and refactors into the larger issues.
The skill gap between the most able and the weakest programmers can be enormous. What's the best way to deal with this? How can you stop a weak programmer being a drain on the team? Does PairProgramming bring the weak ones up or drag the strong ones down?
This is not PairProgramming problem. If anything PairProgramming may mask this issue, because good team members might be able to make up for a bad team member.
If you have a team member that isn't a peer to the other team members because of something other than experience, then they shouldn't be on the team. Having someone that just doesn't get it, they won't help your team whether it works in pairs or as solo developers. This is a management problem. People who don't fit should go. Does it matter if they are:
* Too unwilling
* maybe they don't care what other programmers want them to do
* maybe they don't believe in test first, so they never do it, even if it is the team rule
* maybe they don't follow the design standards or the coding standards
* Too "stupid"
* maybe they say they are trying but the team sees no results
* maybe they are observably trying hard, but the team sees poor results
I suggest that it doesn't matter. The team member doesn't fit. Find a fit for them elsewhere. This is no different that the BrilliantProgrammer? who doesn't fit in the team. If they don't fit, they don't fit. Help them find a new place to be.
On the other hand, if the team member is willing and trainable, then get them up to speed as fast as possible.
If there are LessAbleProgrammers at your job, and you don't want to pair with them, talk to your manager about improving the over-all team.
What are they going to do about it, even if they believe it isn't you that's the problem? You can't fire anyone unless you want a lawsuit, and there's only so much they can do to wiggle people around.
Or maybe you should find a team in which you fit better.
In my experience, there's not much you can do about a LessAbleProgrammer. With enough guidance and assistance, a LessAbleProgrammer can accomplish something. However, it's often more productive for the MoreAbleProgrammer? to do the job herself while the LessAbleProgrammer surfs the Web.
Generally, a LessAbleProgrammer lacks the raw ability, even if they are motivated and hard-working. Transferring that person elsewhere just transfers the problem to another team.
You should inform your manager about the LessAbleProgrammer, mainly so your manager can adjust the team plan accordingly.
What if you *are* the LessAbleProgrammer? Everyone here assumes he is the superman! I've worked with so-called MoreAbleProgrammers?, and they are not necessarily all that productive once you consider the fact they have to interact with others.
First step: Evaluate your situation honestly. If you don't have the aptitude become superb in your current profession, find a new one. (Hint: MoreAbleProgrammers? became reasonably Able within months of entering the field. Excellence in this field not merely a question of learning skills and of experience, but also of innate aptitude.)
Your complaint about MoreAbleProgrammers? sounds like sour grapes. Great programmers interact with others wonderfully. (I'm sure many have their patience taxed severely by having to endure too many LessAbleProgrammers too closely, too often, as well as enduring the other nonsense currently reigning over our industry. Frustration levels are very high these days.) Ironically, the wording of your complaint about MoreAbleProgrammers? actually asserts the premise under the major question of this page - that LessAbleProgrammers are a "drain on the team".
Are we taking the word "less" as relative to some absolute standard, or relative to the mean? Because if the latter, there are always going to be LessAbleProgrammers, and it's ridiculous to claim that all such should seek other professions.
You are correct, this snotty poster is ridiculous. Of course, he thinks he is a "superb programmer", faced daily to put up with the slings and arrows of his outrageous misfortune of having to constantly deal with those people with lower IQs and hence less programming ability than himself. Oh, and of course, he defines programming ability here so that, by definition, the less able programmers can't interact with others, whereas the superb such as himself necessarily by definition interact with others "wonderfully". In other words, he has a very simplistic model of the universe, where there are the supermen, the superb, such as himself, who excel in everything, and then there are those that get in his way and mess things up, because they are universally worse at everything they do.
''Not more snotty than the one above who redefined "More Able Programmer" to "can communicate", which allows him to consider himself more able. See the comments at the top for examples on how to redefine "driving skill" so it fits your driving style. This is exactly the same, with one little exception: communication skills are not the hallmark of excellent programmers. That's the main reason why they are called "programmers" and not "communicators".''
From a managerial perspective, I rarely see "More Able Programmers" and "Less Able Programmers." Different programmers perform differently. On some types of problems, certain programmers do well, while others flounder. On different problems, the roles reverse. I am constantly face with the choice of assigning certain types of problems to certain programmers to get them resolved quickly as opposed to assigning them to others for the learning experience.
The only exception I have seen to this rule is the learning curve for a new team member. It can take 6 months to 1 year for someone new to come up to speed and be a competent member of a development team. After that, he will show his own unique set of strengths and weaknesses.
I always see "More Able"s and "Less Able"s in every profession.
It is really WishfulThinking to expect everyone to perform the same in every action, or even one person to perform the same in every action, however, some people are simply better that others in activities related to programming. Fitting people with activities is a good management habit (praise on you), but discovering NetNegativeProducingXrs?, and sometimes firing them, also.
I am a manager, a professor and a consultant. I've seem my quota of incompetent professionals in every profession. It is much harder to see a competent professional. Currently I work with 3 very good programmers with different characteristics. I fit them to the job I assigned. However, 2 others, that just left the company, are bad programmers and there is no short term training that can fix that. Why? Because they are slow to learn and dependent people. Pair programming, for them, is asking for help, not for collaboration. How many time do I have to change all their behavior to a better one? I am running a company, not a school (however, in the University, I do have time to try to change their minds!).
Should I change these programmers to other activities? Usually, not. They want to do what they do badly! It is fun, it is a challenge. However, they do not take the challenge as the other 3. They get lost.
I have another programmer working for me now. He is not a genius, he is not top notch, but he understands what working is and is a good professional.
I really believe (now) that staffing should be one of the most careful activities in a company. Hire only the best for the activity. Don't let time press you.
When I started in my current job I was constantly frustrated by one guy who was noticeably slower than the others in terms of understanding domain concepts and the language we are using. However, as time has passed I have observed that he does in fact do useful work, whereas one of our "genius" programmers spends a lot of time fiddling with very complicated systems that never seem to work. Comparing the two, the slow guy has contributed 20 times more value to the project than the "genius" because he actually does useful work without letting his ego get in the way.
Then maybe your "genius" is a LessAbleProgrammer (because he doesn't get useful work done).
Or perhaps your organisation ought to consider adopting JoelSpolsky's recruitment criteria: SmartAndGetsThingsDone?.
An interesting paper related to all this: UnskilledAndUnawareOfIt: How Difficulties in Recognizing One's Own Incompetence Lead to Inflated Self-Assessments
http://www.apa.org/journals/psp/psp7761121.html
Abstract: People tend to hold overly favorable views of their abilities in many social and intellectual domains. The authors suggest that this overestimation occurs, in part, because people who are unskilled in these domains suffer a dual burden: Not only do these people reach erroneous conclusions and make unfortunate choices, but their incompetence robs them of the metacognitive ability to realize it. ...
Can a team use LessAbleProgrammers? to flesh out simpler parts of the design? Sure, if your programmer is useless, they're useless, but not everybody has to be a genius. Let your better programmers handle the more complex parts of your code and let your LessAbleProgrammers? format reports and the like.
Related:
See ProgrammerStereotype, NetNegativeProducingProgrammer, FourLevelsOfCompetence; contrast with GrandMasterProgrammer
EditText of this page
(last edited January 11, 2010)
or FindPage with title or text search