As successful as we are at handling some sorts of complexity, the complexity involved in programming computers is a different matter. The requirement is no longer to compare patterns in a holistic, or all-around, fashion but instead to be very precise about the comparison. In a section of program code, a single misplaced character, such as "+" instead of "&," can produce a nasty defect that often cannot be easily spotted because its cause is so small. So we have to watch our p's and q's very carefully, retaining our ability to look at the big picture while also ensuring that every tiny detail of the picture is correct. This endless attention to detail is not something at which the human brain is very efficient. Surrounded by a large number of potential bugs, we can sometimes struggle to maintain what often feels like a very precarious balance in our programs.
A programmer employed by my company came to me with a bug that he had found impossible to locate. When I looked at the suspect class module, the first thing I noticed was that one of the variables hadn't been declared before being used. Like every conscientious Visual Basic developer, he had set Require Variable Declaration in his Integrated Development Environment (IDE) to warn him about this type of problem. But in a classic case of programming oversight, he had made the perfectly reasonable assumption that setting this option meant that all undeclared variables are always recognized and stomped on. Unfortunately, it applies only to new modules developed from the point at which the flag is set. Any modules written within one developer's IDE and then imported into another programmer's IDE are never checked for undeclared variables unless that first developer also specified Require Variable Declaration. This is obvious when you realize how the option functions. It simply inserts Option Explicit at the top of each module when it is first created. What it doesn't do is act globally on all modules. This point is easy to recognize when you stop and think for a moment, but it's also very easy to miss.
Some final thoughts Learn to be humble when programming. This stuff is seriously nontrivial (a fancy term for swallowing a rhinoceros sideways), and arrogance when you're trying to write stable code is counterproductive.