Ask HN: What's your proudest hack?

I studied CS engineering at a fancy uni with a pretty strict curriculum.

One year I fancied going on an around the world trip on this program called "Semester ar Sea" (SAS) for a study abroad. This was explicitly out of scope for the curriculum and the dean vehemently roadblocked my request.

My school happened to have one of those design your own major options so I went in and wrote my own major that was something like "cse and international business" and designed the curriculum so that SAS was a perfect fit.

A few weeks later I pitched the dean and her staff on this "engineering with an international context" major and they LOVED it. She signed on the dotted line smiling and that's when I informed the room that I'd be doing Semester at Sea because it was a perfect fit.

Best of all, having a dean stamp of approval, my scholarship transferred over.

So I spent the next 9 months earning college credit living on a cruise ship with 500 other kids traveling literally around the planet. It was one of the best experiences of my life and I could fill a book with stories by the time I finally came home.

To this day I'm not sure if the dean was pissed or proud or both of me

Years ago I was developing firmware for a measuring instrument (an ultra-low current ammeter) based on an 8-bit CPU, the Motorola 6809. I was the first person in the company to use our newly-adopted C language development system with in-circuit emulator. The firmware used interrupts for I/O and was built on an RTOS, so it was multi-threaded. All of the math for measurement processing was done with long (32-bit) integers (on the 8-bit CPU).

Once in a while the instrument's readings were wildly wrong. After we ruled out actual signal glitches in the analog front end, I started poking around with the debugger, which did have some very nice breakpoint capabilities. This is when I discovered that the C compiler implemented long math operators using anonymous function calls. And that these functions were not thread safe (they used temporary variables below the stack pointer)! If an interrupt occurred during a math operation, the function returned a wrong value. Disabling interrupts for long enough to do a long divide was not an option as that would seriously mess up the operation of the analog front end.

I duplicated the functions in assembler, but with proper use of the stack, and then replaced all the naked math operators in my source code that operated on longs with calls to my new functions.

Had a similar but simpler experience with Telegram's Lumberjack game [1]. Wrote a small Python script that scans a few pixels of screen and sends arrow key signals when sees a branch. The game was gradually speeding up to the point that script was not able to keep up yet it was beating any human easily.

[1] https://telegram.games/telegram-games/lumberjack/

Once upon a time, there were computers made by IBM, Wang, and a few others that did nothing but word processing. They were massively expensive, and in the early 80's, were quickly killed off by the WordStar program running on the first wave of commercial desktop PC's.

I was contracted by a law firm to manage about a dozen temp workers to convert 1000s of Wang-formatted files to WordStar. Their IT people had us opening each Wang file with a conversion feature in WordStar, and then saving it. WordStar had to be opened and closed for each conversion. (The PCs got files from what was, essentially, a shared hard disk, but DOS and WordStar ran from floppy disks. I.e., it was all very slow.)

I spent my first few hours on the job figuring out what WordStar was doing. I discovered the conversion feature was a stand-alone program, and then worked out the syntax for feeding it a file. Then I built a batch file that would recursively convert entire directories. Needless to say, I was out of a crushingly dull job in a few days instead of a month or so.

Early in my career in late ‘80s, I was troubleshooting asynchronous communication protocol used for semiconductor equipment. These where streams of data packages carried over an RS-232 serial cable in a hierarchical format that you can think of like XML. These were request/reply messages, but asynchronous. In order to understand which reply messages paired to which request messages, the protocol allowed for 4 “context bytes” in the header of every message. If you send over a context ID of 100 in a request, the reply or replies will include that same 100. Also for your mental imagery, please see me just a year out of college, sitting by myself in a bunny suit in a massive and noisy clean room, sweety hands in latex gloves, and usually fogged up safety goggles because of the mask over my face.

I was troubleshooting a new interface for a piece of equipment from a company called Lambda Ace. Metrology equipment like this one in semiconductor fabs at that time were poor in this protocol. In this case, the context IDs that came back from the tool appeared to be random and far off from what I was sending. I typically sent small numbers and it was sending me huge numbers. I started looking for patterns in the data and once I looked at this in Hex, it all started to come together. The last 2 bytes were always 0x4C and 0x41. In the text version of the Hex dump, it showed those were the ASCII values for the characters L and A, or Lambda Ace.

I was on an Intel processor which stored bytes in little-endian, so those last 2 bytes were higher order bits making the 4 byte number quiet large. The hack was to figure out the constant from 0x4C41 that I always needed to subtract from my reply's context bytes. I also had to be sure I kept my set of context bits to values that fit in the lower order 2 bytes. It was a kludgy hack for sure and I’m sure broke again with future tools of this type.