Hacker News Reader

This exchange has been the long drawn out version of:

> > Story

> r/thathappened

r/nothingeverhappens

---

Where subreddit "ThatHappened" is a sarcastic one, a response to far-fetched and unlikely sounding stories, implying they are not true. Such response has been overdone enough that subreddit "NothingEverHappens" has become a reply implying that unlikely sounding things actually do happen.

And all of it is a real-world version of the joke "a person walks into a bar, and hears one of the regulars say 'number 38' and the other regulars laugh. A bit later another one says 'number 17' and they laugh. The person asks a regular what's going on, and they say 'we have all been here so long and told the same jokes so often that we know all the same jokes and just refer to them by numbers. Try one yourself'. The person says 'number 22'. Nobody laughs. The regular shrugs, eh, it's the way you tell 'em".

But suggesting that joke plays out in real life might be r/thathappens . But it does happen, and people do laugh.

The story is most likely made up and one of the last clarifications strongly hints at it:

> It can't be this simple / this is fake because you aren't doing blah blah. You're right, it's not this simple. There are more steps involved in the script and it performs functions I haven't discussed. [...] The core of the script, transfer and hash, is accurate

The person focuses on transfer and hash and keeps what looks like an absolutely critical part of the process as barely a mention: checking against a spreadsheet where the automation is most vulnerable. Tens of thousands of files means just as many opportunities for a typo in that spreadsheet. And yet the job is still 10 minutes per day.

Also with the popularity this gained, not being worried at all that the employers can guess who this is about just because they left out some parts of the job is a bit hilarious. Somehow I can buy that a mid-sized law firm never realized how easy it is to automate this task. But nobody ever suspecting they're the actors in the story despite the process being fairly unique? That I don't buy.

Everything sounds like a very inexperienced person telling a story they can only fantasize about.

> But nobody ever suspecting they're the actors in the story despite the process being fairly unique?

In a past life I used to write for a local TV soap. I would constantly take personal events that my friends and family told me about, minimally jazz them up, and have them happen to our regular cast. I was there for five years and not one person noticed that their story was on the show. It's all about context.

You overestimate how much managers and employers browse social media. Especially non-tech organization, they may not even know what Reddit is.

And no, this isn't a unique experience, given how many people here alone chimed in on similar automation strategies in non-tech situations. It can be weird if you're in tech and you're managing billion line codebases, but you'd be surprised how much a non-tech company would value a 100 line automation script you whip up in a week. The only risk in that relationship is your skills growing stale for if/when you need to change jobs

“Number 22!”

“We don’t say that one anymore. You’re going to have to leave.”

"Number 73!"

All regulars are laughing, hard. They shout out in turns "73!", and laugh again. Confused, the person asks what's so good about 73. Says a regular, catching his breath and wiping tears from his eyes: "Heh 73, we haven't heard that one before!"

I also agree that it's not only happened, but it's probably not that rare. Before most businesses were automated to the point where this is possible, I had an engineering job where for at least two years, I may as well have not shown up. I spent all my time reading magazines and doing pet projects because there wasn't anything else for me to do but answer the phone if a customer had a question. I could have easily taken on another job in the mean time if remote work was a thing back then.

I knew at the time that I wasn't alone in this. I knew another engineer whose job consisted of basically showing up to work just in case an alarm went off. He spent his time writing a software package that he sold. Because, again, he really had nothing else to do all day, every day.

This was back in the mid-late 90's. I'd expect that it's even more prevalent now.

> As developers who start writing big servers learn, scale matters. Crap you'd never think twice about when running a script on your workstation will bring your entire service down.

This reminded me of an issue we had at a previous startup that was growing really fast. There was a process that "created PDF invoices", which was coded by calling a (sync) API, which generated it on the fly.

The problem changed, once those PDF invoices became 100MB large, with hundreds of pages (required by business case). It's a completely different beast that the "MVP" developers did not thought about (as it is expected). Now you either code and maintain an async service which uploads to S3, along with the full lifecycle, or just buy a service to do it for you.

Scale definitely matters, and all systems change once you consider large scale data and workloads.

wait did you use to work where I work? We fixed this, haha.

I don't think so, but it is a recurring issue I've seen at several B2B startups. It makes sense if you think about it. Being B2B, customers' AP departments request detailed usage billing. Someone creates a simple endpoint to produce a PDF, and eventually PDFs get too large to handle synchronously.

I know sysadmins that did very similar things to what the author is doing and spent their time in the office playing videogames.

It's not that unreal.

> I'm sure this story is happening at least a thousand times over somewhere in the world in some form.

I have done something similar in the past, I just kept quiet and let the script do all the work without telling anyone.