There are many ways to debug your code. You might use an actual graphical debugger, wrestle with GDB, just spam print statements, or rely on a logging framework to help you generate useful diagnostic output.

Since you're going to need some logging output no matter what, it's always good to heavily instrument your code. Using logging levels, you can control quite well what gets dumped when. Well, "LostLozz" had a co-worker who found an… interesting way to control logging.

"I was once working for a company that primarily dealt with Oracle products," Tai writes.

That vendor, who shall not be named again, provided an installer. Tai ran it, and it failed. Since the installer was a shell script, she opened up the file and took a look.

If you browse the Errords, it's easy to see that "giving customers a discount" is apparently harder than it looks.

Brian's company had one of those "discounts are hard" problems, way back when. Sometimes instead of a discount reducing the price, it would raise it. The root cause was that the sales team setting up the promotions weren't clear about whether the discount amount should be a negative or positive number. Instead of adding validation to ensure they always entered a negative (or at least, a zero amount), one of Brian's predecessors fixed the bug in their C# like this:

Powers of two are second nature to a lot of programmers. They're nearly inescapable.

Equally inescapable are programmers finding new ways to do simple things wrong. Take Sander's co-worker, who needed to figure out, given a number of bits, what's the largest possible value you could store in that number of bits. You or I might reach for our language's pow function, but boy, in C++, that might mean you need to add an include file, and that sounds hard, so let's do this instead: