I don’t intentionally put bugs into my code. Do you? Probably not, but having coded for decades I know that those nasty critters sneak in whether we like it or not.
I spent a good deal of time coding in assembler. It was easy to make errors because a programmer needed to do most of the checking. Moving to a high-level language improved the development process, but C traded off some common bugs for others—like using a single equal sign (=) instead of a double equal sign (==), causing an assignment when I intended to do a comparison in an IF statement. Sometimes the code would work because the value being assigned matched the result of what the comparison should have resulted in.
Programmers often dismiss these kinds of bugs as trivial, which they are, but they are ones that can result in problems that are hard to find and fix—ones that cause major headaches when the code is in the field. It is well known that the cost of fixing a bug grows exponentially the longer it is around. Fixing something that has been in field for any length of time is significantly costlier that finding it the when it is introduced.