I'm not sure that there's a simple answer to your question, I'm afraid, Harry.
There are certainly occasions where, once you see a bug the answer to where it probably exists just "pops into your head". But there will be other occasions where you just have to apply time, effort and sweat to dig it out. Nobody ever claimed that debugging was easy ;-)
Having said that, there are certainly some types of code that are "intrinsically buggy" (i.e. you can tell that there's a bug just by looking at the code without even running it). Here's an example in C++
The answer is that x could have any value whatsoever - the C++ standard simply doesn’t define what this code does. In practice, most compilers will do something “sensible” with it, and typically x will end up equal to either 1 or 2. But theoretically speaking, it could end up equal to 42, the program could crash, or anything else could happen. That, unfortunately, is what undefined means.
Interestingly, if you compile the same code in
Java, then its behavior is defined - x will always end up with the value 1. But don’t feel too smug if you’re a Java developer - the behavior may be defined, but it’s still almost certainly a bug. Presumably whoever wrote this code intended it to do something, where in fact it’s a no-op. So, whatever it was they intended it to do, it’s not doing it.
The great thing about this kind of bug is that you can detect many of them automatically by using static analysis (tools that crawl over your code looking for this kind of thing).
As for using buggy code for something else, I fear that you're out of luck. There are far more ways to write incorrect code than correct code, and the chances of a bug happening to solve some other problem for you is very slim indeed, I'm afraid :-)
