Running "strings" on software can reveal a lot of things.

Yep. For decades it was one of the first things I did with commercial software, and I usually got around to it on any other software that I used day-to-day. Not just good for error messages, but also for "undocumented" command-line switches and the like.

I once worked somewhere that left the o out of a select count(*) statement - it somehow escaped testings and a customer found it...

The same place had a bug report from a customer saying "If you see this then talk to 'Pete'".

The customer had a sense of humour and rang the switchboard and asked for him

"If you see this then talk to 'Pete'".

I've seen this in-house once or twice. with nothing else to do i'm like "may as well send x a message see if he still cares"

only to have the dev run to my desk to find out how I managed to trigger it as it's been wrecking his brain that something that should be impossible is occasionally happening

The Roland DR-660 drum machine (early 1990s) has a set of pre-progammed rhythm patterns. Which have to be 6 chars or less to fit in the LCD display. And one of those would have been called "Country", except they had to choose a letter to remove ...

so it mistakenly became 'County'?

It could have became "counry", as in Oi'm a counry bumpkin ... "

Pardon my rusty 4 decade old sql but did the shorter output selector work ?

In most places select * .... would produce identical output.

I used to do that too. Except that I encoded the messages such that they wouldn’t be revealed by such a trivial search.

Yeah, ROT13 to the rescue.

For even more obfuscation I use double ROT13.

It could be that the sexually-celebrative error message could never be triggered the way the program was written.

If it was merely an unused entry in the error message table, with no error condition mapped to it, it would have just sat there.

Back when I was writing COBOL programs, I used to include a visually-distinctive string at the beginning and at the end of the string literal pool, so that it was easy to find when visually-scanning a dump printout.

Also in IBM software ... a colleague set an message to "Merde!" for one of those impossible to reach error conditions. When the condition proved to be not quite as impossible as he'd imagined, the only real complaint from the customer was that they weren't actually running in the French locale.

MEMS

Working on a parallel program for simulations of bacterial interaction in the gut micro-flora, I got an "Impossible Error: W(1) cannot be negative here" (or something similar) from the NAG library 9th order Runge-Kutta ODE solver on our Cray J932. The thing was, I was using multiple copies of the same routine in a multi-threaded program. FORTRAN being FORTRAN, and the library not having been compiled with the right flags for multi-threading, all copies used the same named common block to store whatever scratch variables they needed. So different copies were merrily overwriting values written by other copies, resulting in the impossible error. I ended up writing my own ODE solver

Having achieved the impossible, I felt like having breakfast at Milliways

Multi-threaded FORTRAN. Alrighty, then. There's a nightmare I didn't know was possible. I'm going to need something a bit stronger than tea.

I'd need a Pan-Galactic Gargle Blaster before going back to Fortran in any shape or form...

It's that kind of attitude from kids like yourself that makes coding in Fortran and COBOL the lucrative thing that it is today. Lots of money coding in the pair of them.

I had something similar (albeit a trivial context) switching LEDs on a model railway in Python on a Pi. I merrily multi-threaded the provided routines for the I/O chip not realising they did a read-before-write to establish the current state, which of course then changed between read and write. The flashing light show wasn't quite what I had in mind for my simulated fluorescent tubes starting up, although it was easy enough to fix by writing my own routines that used a global variable for the current state,

Saul Goodman.

Yet to find anything explicit but I have come across internal software that had such things as "Greg's super hacky script starts here" come up in the debug logs.

One wag among the devs had a habit of putting after the log message for a finished test run.

My favourite was the pop-up that had the title of "Oops" with the explanation text of "This should never happen or be possible, the program will now close."

Reaching the end of an error reporting trap that printed a message for each foreseeable error I put in a message for anything unforeseen, which was of course, to my mind, an empty set. The code went live and I thought nothing more of it for a decade or so, until a colleague that I hadn't worked with for may years sidled up to my desk with a handful of piano-lined listing paper containing this message. "Did you write this? We thought you'd like to know that it happened last night".

Failed disc sector. Never forget the hardware.

I wonder whether it was triggered by the floppy (oo-er missus, fnar,fnar) disk insertion event?

I recall back in the very early 1990s as a trainee Accountant I was assigned to a piece of work in a department using Macs, which had that particular event set up with a similar sound file triggered.

One of the other things I learned about Macs that day was where the volume control was.....

One place I worked at (though this was nothing to do with me) received a call from a confused customer.

Customer: "I was trying to get your software to do X, but I wasn't sure how to do it so had to play about".

Support: "That's ok, it won't let you do anything bad".

Customer: "Yeah, I know that. However, it just told me "9 out to 10 intelligent people would have worked this out by now"".

Turns out someone had put some code in that spat this out if the same error occurred 10 times in a row.

Luckily, the customer just thought it was amusing and was calling to say "well done".

Friend was working for a large corporation during his vacations at uni.

Task was to process large amounts of data from the command line using a very, very under-powered PC (so the job took a long time to run).

He decided that some sort of progress indicator was needed, so he added various "helpful" messages to indicate where the processing had got to in the various loops and procedures.

"Tum, tee-dum, de-dah, ta-ta".

His manager was not impressed - even though the program satisfied all of its functional requirements.

All of sudden I am reminded of the VME order code 33552 - UM_HO_HUM_NOTHING_TO_DO which indicated that there was no instruction waiting to be processed.

I remember snooping around in the executable for WordStar on CP/M. The string "Nosy, aren't you?" was what caught my attention.

There was also some obscure error in one of Oracles packages some decades ago. I don't recall the exact message, but it was something like "It looks like you don't know what you are doing."

Oracles packages some decades ago - "It looks like you don't know what you are doing."

Running anything from that infernal pit today pretty much confirms the prophesied incompetence.

Was anyone from New Zealand?

I once worked with a chap who, in a previous life, had been a developer for an AIX based accounting system.. He recounted the story of being called into his manager's office to discuss a recently received complaint. A customer using the software suddenly found himself kicked out of the screen he'd been using and was instead presented with a screenful of code, the final line of which read "What the fuck are you doing in here...?"

Neither the customer nor the manager were best pleased, which apparently contributed to the career change.

"The other was that despite his efforts, he never did manage to trigger the error!"

Probably because it was impossible. Including an error message that can't be triggered isn't difficult. Or the programmer would never have included it. *

* Not unless he/she was leaving.