We know that majority of programmers, even the most ingenious ones, are egotistical bastards, driven by arrogance.
Programmer's arrogance is both a blind, powerful driving force and also the reason for many failures.
For example, anecdotal evidence tells that initial programmer's estimate has to be multiplied at least twice to get the "realistic estimate":
Why are competent coders so bad at estimating? There are a number of reasons. The main ones are:Or they just fall a victim to their own arrogance. Which is a bit simpler explanation.
Many of the problems that come up during software development are unforeseeable. If you have ever started a "simple" home improvement project and later found it was much more complicated than you realized...then you know first hand how programming can be...even for the experts.
- Unforeseeable problems:
When the requirements are unclear, the programmer usually underestimates what it takes to build your software. To use an analogy, they may estimate building your software as if it were a comfortable house. Only mid-project do they realize that you were expecting the Taj Mahal!
- Misunderstood/unclear requirements:
Same stands for "Not Invented Here", "Invented here but not by myself", "My co-workers are all jerks" syndromes. And many more. Oh well.
Now, I've got a theory (which is built on empirical experience, of course), that if we imagine that amount of "arrogance" can be measured with a scalar value (let's call it a "magnitude of arrogance"), and if we try to build a graph of this value changing with the lifetime of the programmer, we might get pretty similar shape in 80% of cases:
The person (remember that we talk about future programmer) starts on some level of initial arrogance as a child/teenager, goes to school where everything is very new and unknown at first (point marked as "S" on the lifeline, which is horizontal).
But then he (not being sexist, just intentionally taking only males here) suddenly realizes that he's the "smartest kid in the class". The next thing he figures out is that his programming teacher "does not know a sh*t". Besides some boring, irrelevant and ages old stuff, that is. And sure he does not have any bleeding edge knowledge about, say, patching KDE under freeBSD.
Naturally, this skyrockets the level of arrogance significantly, and it keeps fluctuating somewhere at the top until our geek graduates and gets a job ("J").
Here the arrogance might drop down slightly again, because of the things being new and not familiar.
However, being used to the "best kid in the class" status, our soon-to-become programmer quite quickly catches up.
It might happen because of initial tasks being moderately doable and initial responsibility being not quite high, so this "gee, I can do the stuff" feeling warms up the ego.
Also, when coming to a corporate environment, young programmers often get a maintenance job in some legacy codebase. Knowing the nature of (most of the) legacy code bases, one would not get surprised if quite soon our kid gets to realize the thing.
See, it happens that all these "experienced" folks out there don't know a sh*t about programming either. As Gerald M. Weinberg puts it:
We often find material in programs that is [...] really present because of the history of the development of the program. For example, once the [...] function is changed to an [...] function, there is no longer any reason for the program [...] to appear. Nevertheless, things being what they are in the programming business, it is unlikely that anyone is going to delve into a working program and modify it just because the definition of [...] function has been changed. And so, some years later, a novice programmer who is given the job of modifying this program will congratulate himself for knowing more about [the subject] than the person who originally wrote this program. Since that person is probably his supervisor, an unhealthy attitude may develop - which, incidentally, is another psychological reality of programming life which we shall have to face eventually.
Soon he realizes, though, that things do not quite work as it appeared at first. There are several failures happening, which he fortunately realizes should be blamed on himself, and he suddenly faces the understanding that he knows, in fact, nothing about his job.
Then goes a long and painful learning, getting better and better every day, and finally getting to the next level of personal development, where one can look back and say: "see, I am not nearly as lame as I used to be when I started".
So we get another boost of overconfidence, which may or may be not followed by similar, multiple and abrupt drops and consequent slow raises.
What usually happens next is the point "P".
Which is promotion to the lead position (it does not seem that there is too many ways to get "promoted" in corporate programming business without becoming a manager), or becoming an entrepreneur, or changing the working place to work in considerably more "advanced" company. You name it.
The fresh feeling of power gives another arrogance boost. It only lasts that long, though, and soon again come disappointments.
And so on.
After many bumps on the road, if being lucky, passionate, persistent and introspective, one might slowly approach the level, which is marked as "H" on the vertical axis.
Which is "The Humble Programmer", as E.W.Dijkstra puts it:
We shall do a much better programming job, provided that we approach the task with a full appreciation of its tremendous difficulty, provided that we stick to modest and elegant programming languages, provided that we respect the intrinsic limitations of the human mind and approach the task as Very Humble Programmers.The question is how close projection of this point upon the horizontal axis will happen to be to the point "R" (retirement).
And to the point "D", which comes next.