He certainly did. There is no amount of experience that makes people not feel stupid about those. What changes is that you learn to not be affected by it, because you know that it's not a personal flaw (at least not one specific to you), and while you can improve on it, you can't completely fix it.
But the alternating between feeling like the dumbest person on Earth and the smartest person on Earth never goes away.
After at least a few hours away (ideally not coding) your fresh eyes will often spot it.
Similarly, demoing the bug to someone else is a good way, and often through the mere act of demoing it you'll find it yourself (also known as "rubber ducking" [1]).
bool condition = /some really long boolean value with AND and OR clauses/;
if(condition); { /* some code to execute if TRUE */ }
1. It's much easier to notice that incorrect semicolon
2. Even if you don't, you can stick a breakpoint (or log) between when condition is set and when it is evaluated, to convince yourself it works.
3. All modern compilers will produce the exact same code as they produce with it mashed into the if()
if(!condition) is a much better read and less prone to errors than trying to negate a long statement inside the if().
This pattern also eliminates duplication. I have fixed bugs in code where the same long if condition was duplicated several times within the same function (probably with cut and paste). This wastes cycles recalculating it each time and runs the risk of changing one of them without changing them all.
bool subCondition1 = /* something kinda long */;
bool subCondition2 = /* something also kinda long */;
bool subCondition3 = /* something absurdly long */;
bool condition = (subCondition1 && subCondition2) || subCondition3;
if (condition) {
/* do something */
}
Your change also got me thinking of unit tests: at some point it becomes worthwhile to have dedicated tests on that condition, and that's often easiest by putting it in a static method, and that also improves readability.