Those on the RAM disk of course, unfortunately we had a power failure.

When viewing this I got the footer quote "%DCL-MEM-BAD, bad memory VMS-F-PDGERS, pudding between the ears".

I find it very suitable to this article.

Well - I had a similar network card experience once, an 8-bit card was incorrectly identified as a 16-bit card. Some digging and I found the driver code that made the wrong assumption and patched it. I should have filed a bug correction on the kernel but I never did, and today it's pretty much no point in doing it. Card in question was a 8-bit Western Digital compatible card from Accton.

It's way too common that people re-use variables for different purposes. Especially in Visual Basic.

It's also a good way to ensure your code only works on your favorite platform!

Only 4 days - that's good for a problem like that - especially if you are junior.

Programs that crashes when running under a debugger are always fun, sometimes it's better and easier to run the program normally and then do a post mortem on the core file generated. Hence "generating core dumps" is a standing joke in some development.

Fortunately the number of cases where a debugger don't work have diminished greatly over the years compared to how it was under MS-DOS.

On the level of someone changing order of columns in an indexing for no particular reason, possibly because it looked better to have the index column in alphabetical order.

Or just have the path variable set wrong - current directory last in the path can yield some interesting effects when coding.

Bug #1 - not a bug really. Just an awkward mistake, but good that Bloomberg dropped it. But that also shows the need for documentation of how stuff works when someone quits.

I once developed an SMS gateway and did a test run on it but forgot to change the list of phone numbers so my manager at the time got 50 text messages with the same content. Ooops! :)

I see one reason to write clever code - and that's when you try to optimize for performance. But the "hot spots" in code are rare, so in those cases you can get away with it if you put in a decent comment in the code describing why it's done in a particular way.

Multithreading is also a special beast - looks simple, is simple to implement but you really have to watch out if you have shared variables/memory. It can lead to some not so obvious errors!

That's why you comment in the code why something is done there.