A few years ago I had to work with an obscure 90's era embedded microcontroller with a proprietary language and IDE, and a serial adapter based programmer and debugger. The IDE sucked, and programming would fail 9 times out of 10, but at least the debugger was solid.

By complete chance, I happened to interview someone that had, "wrote the debugger for that obscure microcontroller back in the 90's," tucked away in their resume. It was hard not to spend the entire interview session just picking their brain for anecdotes about it.

You were interviewing them for an unrelated role? Just trying to understand why that would be 'complete chance' and that you (by the sounds of it) didn't hire them to keep picking their brain on it.

The role, although also in the field of embedded software development, was indeed unrelated to that particular technology or its use within the company.

Was it some MCU from Rabbit Semiconductor?

It must be great to wake up to some jerk shitting all over your work on the front page of HN.

Fortunately not something ive had to experience!

Never doing anything of note pays off yet again!

(speaking for myself, not you, to be clear)

While praise is best, I'd rather have my work be criticized than ignored. Nobody criticizes something that doesn't matter to them.

I always have the same thought before I set out and write a blog post like this. Shame this author doesn't.

I spend my days scraping and reverse engineering various embedded legacy systems and a recurring thought is "Who is the braindead person who specified or implemented this?" Then I realize those bad technical decisions most of the time end up in production due to business concerns. Often they show a clear misunderstanding of how the underlying tech works, i.e. inexperience. Only rarely those bad designs seem to stem from pure incompetence.

That said, my frustration still gets converted into not-so-polite comments in the source code the culprits will never see.