human interactions are never narrow, never straight, and hardly ever in the directions shown an organization charts. Many serious mistakes have been … - Gerald M. Weinberg

Overconfidence by the programmer could be attacked by a system that introduced random errors into the program under test. The location and nature of these errors would be recorded inside the system but concealed from the programmer. The rate at which he found and removed these known errors could be used to estimate the rate at which he is removing unknown errors. A similar technique is used routinely by surveillance systems in which an operator is expected to spend eight hours at a stretch looking at a radar screen for very rare events — such as the passing of an unidentified aircraft. Tests of performance showed that it was necessary to introduce some nonzero rate of occurrence of artificial events in order to keep the operator in a satisfactory state of arousal. Moreover, since these events were under control of the system, it was able to estimate the current and overall performance of each operator.

Programs, like any other human-made objects, are designed — or should be designed — with a definite lifespan and scope of application in mind. Like the “Deacon’s Masterpiece,” which was “built in such a logical way it ran a hundred years to the day,” a program should have neither over-designed or under-designed parts. Yet it is an occupational disease of programmers to spend more time on those program parts that present, for some reason, the most intellectual challenge rather than on those that require the most work.

If your whole team consists of novice programmers, your expertise will give you considerable power; but if the other team members are also experts, they will attach less importance to your technical expertise. In that case, they’ll pay more attention to organizational power, like the power to acquire extra hardware, to extend the schedule, or to capture a more interesting assignment.