Creator vs Destroyer: As a law of nature – creator can not be a destroyer. Similarly, in software, a programmer can not be a critic of his own code.
Constructive Criticism: A good programmer will always love and admire his code, but will never have that ‘third eye’ (that a tester has) to locate bugs in the code. A programmer is fond of listening to ‘praises’ for a well-written code than listening about the shortcomings in the program written by him.
The vision of a tester: A programmer will always think of the positive conditions in most of the cases and will bother less about the negative scenarios. A simple example could be that the programmer has to write a code to accept a password that has to have minimum one special character, two numerals and length not less than 8 characters. Once this condition is fulfilled, the programmer will be more than satisfied – but what about n number of different test cases that a tester creates just to check this simple requirement.
Fear Factor: Even sometimes when a programmer knows about a flaw in his coding, seeking a major change and coming into his notice at a later stage, he will like to oversee it and also try it to be to be overseen by others. He may fear that highlighting a shortcoming in a code written by him at this critical juncture may loosen up his superiors trust in him, which is usually dear all everyone at any cost.
Thinking Pattern: Walking on the Same Road everyday makes one perfect on that road but what about other road patterns, walking backwards etc. Continuous Coding, Coding and Coding make him a perfect coder but only a perfect coder.
Documentation: Usually a coder writes code perfectly but with very little or no documentation. At times, he himself forgets what logic has he written for a specific requirement and then he has to refer to his own code (and waste some time) to find it out.
Self Testing: The confidence (or over confidence) stops a coder to introspect or examine his own coding by doing smoke testing or jotting down some test cases and scenarios to run them and get a pass through for his own satisfaction.
Tight Schedules: A programmer is always having his task basket full and has delivery schedule tight. That also becomes one of the reasons for passing on some bugs (in a hurry).