I've recently been enjoying the material on the Situationist Blog, which covers interesting articles and topics related to perception and how context influences our thinking. A recent post entitled "The Situation of Illusion", quotes from another book on how a magician performed his famous birdcage vanish:

. . when Blackstone did his famous
birdcage vanish (a cage with a live bird vanished from his bare hands) he would hold his arms outright in front of him, seemingly presenting
the cage to the audience for their inspection. . . . The cage was
specially designed to collapse on command. At the appropriate time, Blackstone would toss it forward, and the collapsed cage would be
pulled up his sleeve – bird and all. Savvy adults watching the show
might shake their heads and say, ‘Nah, it couldn’t go up his sleeve
because he wouldn’t want to injure the bird.’. . .

* * *

Actually, in many cases the bird was injured or killed. [Emphasis theirs]

In doing maintenance programming, this same effect appears. Often I look at a piece of code, read it over a few times to try to understand what it is doing and how it is attempting to accomplish that task and I say, "They can't possibly doing it that way. That would be ludicrous!" So I read it again and again trying to convince myself that I am missing something or that the task to be performed is more complicated than it seems. "Nah", I say to myself, "they woudn't use a linked list here, they need quick index-based access to the data". But looking at all those iterator functions that count up to a particular value, only one possibility is clear: they are injuring or killing the bird.

I want to believe that all programmers are good, and that if they might not choose the same method of attack that I would, they at least choose a sensible approach, but frankly, I think I'm giving a lot of coders too much credit. Whether it's because of tight deadlines, an ignorance of existing libraries, a limited knowledge of algorithms, or just not caring, a lot of bad code makes it into good systems. Accepting that you will encounter a lot of hideous suboptimal code actually makes your job easier. Instead of wasting time assuming that you must be missing a critical fact, you can focus on repairing and improving those terrible sections.