Ask HN: What's your "it's not stupid if it works" story?

An aggressive stemmer might stem both "generic" and "general" to "gener".

Then if your query is "what documents contain 'generic'?", you look in the index for "gener" and then open each of those documents and check if it actually has "generic" using a stricter stemmer (that accepts generic{,s}, genericness{,es}, genericit{y,ies}, generically ... this is a bit of a bad example since they all have the prefix directly). The cost is acceptable as long as both words have about the same frequency so it doesn't affect the big O.

Of course if you have any decent kind of compute, you can hard-code exceptions before building the index (which does mean you have to rebuild the index if your exception list changes ... or at least, the part of the index for the specific part of the trie whose exception lists changed - you don't do a global lookup!) to do less work at query time. But regardless, you still have to do some of this at query time to handle nasty cases like lie/lay/laid (searching for "lie" should not return "laid" or vice versa, but "lay" should match both of the others) or do/does/doe (a more obviously unrelated example).

All of these other anecdotes are (understandably) sysadmin or developer-related, though I have a couple very stupid ones that are completely physical and mechanical.

My first residential plumbing fix was a simple unclogging of a shower drain, which was accomplished by putting a couple inches of water in the tub and blasting repeatedly into the drain with a pneumatic cannon. The splatters hit the ceiling, but it was thoroughly unclogged after a few repetitions.

The second major one, was the sewer line at mom's place, which ended up being very bad clog that nasty industrial drain cleaner would not even touch. I capped every drain and vent in the entire house, and dumped two 30 gallon compressor tanks of air into the two toilet hookups. There was great and concerning watery rumbling from all through the house, but after a 30 seconds or so, the clog was blown into the septic and has not given her a single problem since then.

In 2012, Intel had a site called esaa-members.com. It was supposed to be some type of authorized hardware catalog, with recipes for building computers out of known-to-be compatible parts. Anyways, there was a daily import of the hardware data, which was kicked off by a small Ruby script that downloaded some CSV file over SFTP. It was tiny, and all it did was put the CSV in a folder, to be processed by another script down the line. Occasionally though, there would be a network error, and it wouldn't write the file. When this happened, the next script that looked for the file wouldn't find it, and would send out an email alert.

That's when I discovered that you could write a GOTO statement in Ruby! I made a very minor addition to the beginning and end of the script, a label at the top, and a goto at the bottom for if the CSV file didn't exist. I had added my email to the list of alerts, and after that GOTO was added, I never saw another alert.

...an awful one for posterity: an abomination of vim + awk as a proto-protocol plus UI editor.

Basically awk would match `/^FOO / { system("foo.exe $0") }`

...you could get pretty darned far with that mechanism, for near minimal amounts of code.

Any time you pressed "enter" on a line of text in vim, it'd get thrown through that awk script.

If a line matched a command matched in the awk file (think GET, POST, SEARCH, ADD, etc), it'd execute that awk block, which was often just calling over to another executable which did the searching, adding, etc.

The interesting thing about it was using it as a UI... you could basically "expand in place" any particular line... have commands return subsequent commands to pick from, etc.

Plus the ability to "undo" via vim commands and the fluency of effectively an ad-hoc REPL was a really liberating experience.

Not my idea or implementation.

Our startup built a plugin for Microsoft Outlook. It was successful, and customers wanted the same thing but for Outlook Express. Unfortunately, OE had no plugin architecture. But Windows has Windows hooks and DLL injection. So we were able to build a macro-like system that clicked here and dragged there and did what we needed it to. The only problem was that you could see all the actions happening on the screen. It worked perfectly, but the flickering looked awful.

At lunch, someone joked that we just had to convince OE users not to look at the screen while our product did its thing. We all laughed, then paused. We looked around at each other and said "no, that can't work."

That afternoon someone coded up a routine to screenshot the entire desktop, display the screenshot full-screen, do our GUI manipulations, wait for the event loop to drain so that we knew OE had updated, and then kill the full-screen overlay. Since the overlay was a screenshot of the screen, it shouldn't have been noticable.

It totally worked. The flickering was gone. We shipped the OE version with the overlay hiding the GUI updates. Users loved the product.