We used them on the bitty boxes back in the days of PC-DOS and MS-DOS, too.

Some were just viewers, but most had an edit mode and a few even handled inserts. I knew a few guys who could write small DOS executable programs using nothing more.

In any case, they were very helpful for debugging, for fixing typos in the strings contained in compiled programs (which is scary using a text editor) and for reverse engineering data file formats or even code.

A good hex editor is great even for hybrid code/data files in the few instances one runs across those. For example, lots of DOS system utilities had their own password schemes since the OS had no security. I had forgotten my password for Norton Utilities (version 6) a couple of times and had to reinstall the package. I got tired of that, so I did something about it. A hex editor was a big part of the toolkit I used to figure out how the package stored its password and how to change or disable said password. It was also my preferred tool to use when changing the password until I wrote a specialized program to do that.

As for the specifics of the story, in case anyone's interested... It turned out the password was encrypted with a fairly basic cipher and stored inside all the individual executables it was meant to protect. I was too lazy to figure out the cipher itself as code, as I figured out there was a simple mapping of plaintext to ciphertext first. That and the offsets in the files to put the new data were all I needed to know. A friend had me try it on his NU v7, but the scheme used for that didn't seem to be quite so simple. I gave up before figuring it out, and stuck with v6 the rest of my DOS-using days since I always had this trick. I doubt my particular find and the change in tactic for the new version are related, as it's probably coincidence. Let this be a lesson, though, that security through obscurity does not work.