common programming mistakes

One of the most common mistakes people, including programmers, make about computer code is assuming that a program is a piece of text for communicating with a computer. It is not. A computer program is a piece of text written by a programmer for communicating ideas to another programmer.
The computer doesn't care about clarity, organization or modularity. For that matter, it is only passingly interested in syntax, naming conventions or even language choice. Once it's compiled, it's all assembly code, as far as it's concerned. It will execute it flawlessly every time, because there is never any room for misunderstanding at this level.
The purpose of a program is to clearly communicate the solution to a problem to another programmer. If that weren't the case, we'd all just be programming in assembly and be done with it. Programming languages are about adding abstractions to the solution that make them easier for humans to think about. They are for communicating ideas that can, incidentally, be compiled down to something a machine can run. They help us explain complicated problems to one another, so that they can be modified and maintained over time.
Remember, the most important person you are explaining things to is you, six months from now. Code for that idiot so that he or she can easily step back in and understand things and you're in good shape. Take short cuts, be cute, be obscure or just be lazy and someone, likely you, will pay for it later.
But too few programmers realize this. They are enchanted with obscure features of the language, feeling superior to other programmers who do not know the fine details of the Microsoft ATL template instanciation code. They are under a crunch and use their finely detailed knowledge of the program to make something that takes less time to type, rather than explain things clearly. Or they grew up with Fortran and program a single, thousand line long function that does everything, cutting and pasting twenty line segments over and over with a few key modifications. I've seen all of this and worse.
What happened here is not completely PGI's fault, but rather a fault of the industry and of the education system that supports it. The programmer in question wrote code so that it would work, not so that it would be clear. Some of this unquestionably is due to unrealistic timelines (PGI) or a lack of stress on unit testing (PGI). But the rest of the problem comes from a cultural issue in the software industry right now; programmers are taught to program a computer, rather than to explain an idea.