Some years ago, when Cobol was the great white programming hope, one heard much talk of the possibility of executives being able to read programs. With the perspective of time, we can see that this claim was merely intended to attract the funds of executives who hoped to free themselves from bondage to their programmers. Nobody can seriously have believed that executives could read programs. Why should they? Even programmers do not read programs.
Perhaps we expect too much from schools. The education process is still essentially medieval in its practices, so why should schools for programmers be different? Typically, where there is a carefully worked-out educational program, it is to train future professionals with amateur habits, so perhaps it is better that they don't do much of a job. At least there's less to unlearn once you get into a real programming environment.
In September of 1962, a news item was released stating that an $18 million rocket had been destroyed in early flight because "a single hyphen was left out of an instruction tape."... The nature of programming being what it is, there is no relationship between the "size" of the error and the problem it causes. Thus, it is difficult to formulate any objective for program testing, short of "the elimination of all errors" - an impossible job.
Maxwell, the great physicist, once said, "To measure is to know," and his words are often taken as a motto by other sciences. What Maxwell probably meant was "To know how to measure is to know," or even better, "To know what to measure is to know"... Knowing what is worth measuring, the physicist can narrow his experimental field to those matters. In a sense, physics is the science of those things a physicist can measure.
Managers often form a [programming] team which by any reasonable judgment cannot perform the designated task in the allotted time. Inevitably the team is given an extension when the time limit is reached and the reality must be faced. Had it been faced earlier, the work could probably have been organized differently - in recognition of the longer schedule - and thus produced, in the end, more quickly.
The greatest danger is the manager who has come up through the programming ranks and wants to define every bit and byte before the team even sees the problem... When a team does work from this sort of 'bit-picking' specification, other troubles arise simply because what the group is trying to accomplish is not clear. Precision and clarity are not the same. To be clear, the task outlined must be placed in a framework of the meaning of what is being done. The programmer wants to know why, not just what.
We frequently see a team leader removed from his post for refusing to promise achievements which his team believes are impossible. The process of replacement then goes on until management comes up with a candidate with more desire to advance himself than brains to assess the true chances of success. Unfortunately, if the project is a long one, this candidate may be promoted for his cooperativeness before the project fails... This game, played over and over, has put more than one programming manager in the position he has today.
An amateur programmer is looking for a way to get the job done. If he runs into a difficulty, all he wants to do is surmount it - the manner of doing so is of little consequence. Not so, however, for the professional. He may be well aware of numerous ways of circumnavigating the problem at hand. He may even employ one for the immediate purpose of getting the job done. But his work does not stop there; it begins there. It begins because he must understand why he did not understand, in order that he may better prepare himself for the programs he may someday write which will require that understanding. The amateur, then, is learning about his problem... the professional, conversely, is learning about his profession, and the problem being programmed is only an incidental step in his process of development.
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.
Lacking any objective measure, we often judge how difficult a program is by how hard a programmer works on it. Using this sort of measure, we can easily fall into believing that the worst programmers are the best - because they work so hard at it. A case in point was a programmer who work 14 hours a day, seven days a week, for eight weeks to get a small program running in a new installation. For his efforts, his company gave him an award for exceptional service. Shortly thereafter, another programmer was given the job of making some additions to this program. He found that the program was such a confusing mess that it was easier to rewrite it that to try and modify it.
Programming a computer does require intelligence. Indeed, it requires so much intelligence that nobody really does it very well. Sure, some programmers are better than others, but we all bump and crash around like overgrown infants. Why? Because programming is by far the hardest intellectual task that human beings have ever tried to do. Ever.
Every four years, along with county elections, the local computer science professors raise the question of the correct teaching language for programming. There's a lot of brave talk about throwing the rascals out, many lunches devoted to campaigning, a wave of confidence just before the election, and then the ultimate defeat for the upstart. In the end, both Fortran and the sheriff are reelected. They may be corrupt; they may be incompetent; they may be creaking with age; but at least they're familiar.
Brains require stimulation. If you're locked into a pattern of work, work, and more work, your brain soon habituates - the same way that it lets you stop hearing a clock ticking. So, if you want to be more effective at work, you must, paradoxically, be less single-minded in your devotion to work. Anything you do - anything - that stimulates new segments of your brain will make you a more effective programmer or analyst. I promise, with a money-back guarantee.