24 comments

[ 1.8 ms ] story [ 35.8 ms ] thread
As a dev currently working at a company where getting an access request fulfilled can sometimes take weeks, I feel this author's pain.

But it seems like an enormous security hole, even with a codeword "password". The author didn't mention it, but I hope they're using whatever version of their company's E2E email encryption is for these messages.

that guy is a fuckin legend
I knew a guy who would brag that he used Outlook as his build system 20 years ago. Builds would take 9 to 24 months depending on the complexity of the project. But, as the CTO of a mid-sized software company, it worked for him.
Memories of waiting for months to get access to a MS SQL database and ending up putting an Access database on a network share for multiple user access instead. A horrible, horrible hack solution. But it worked!
> A horrible, horrible hack solution. But it worked!

I ended up building an Access app at an enterprise-y company I used to work at because it would have taken years for IT to build it. The app did something super specific and kept needing super specific additional features, and there wasn't anything on the market that met our needs. The Access UI talked to another Access database on a shared network drive. I just found out that it's still being used heavily by several people every day, 17 years later. You pretty much nailed it, Access is hacky, but it works!

Edit: grammar

Not intended as an endorsement, but Access / FileMaker / 4D were all great solutions for low-contention, low-user count low / no code CRUD apps.
>Shoddy stuff that has no chance of making its way into production is permissible

That's cute.

I don't know if Telegram, Slack, Discord, GitHub Actions, GitLab CI, Jenkins, or Kubernetes will be around (or without massive breaking changes) in 20 years, but email absolutely will be.
Might need to implement this at current project but with Teams
Realest post I've read in a long time

Hacky is as hacky does.

/Mail/Messaging in SMTP, and you have what it is: A message broker and queue. It has durability, retries, everything
>When you leave software developers alone for too long, they start developing software

I've gotten so bored at work lately I've been coding for fun again

You can use git as a backend for an MTA and come full circle...
Long ago, I used to work at some bank, where SVN branch merging was always super painful and instead of solving people problem, there was holy, e-mail based system running on our common dev machines.

After recieving properly formatted email, script was executed to apply git merge between svn branches. In case of merge issues, the email was sent back with feedback. If everything was okay, a proper sign-off blessing by one of the technopriests as late check was applied and merge concluded.

Good. The next step is turning that into an OS. From there, you should be able to take it further and fully support virtualization.
I can not believe blogspot is still alive. I just went there and it auto-signed me in via my Google account to "Blogger" where there are some posts from Google's blogspot. The last post was in 2020 https://blogger.googleblog.com/
> In industrial scale software development, gaining access you are fully entitled to can sometimes take weeks.

4 years in consulting. I've spent the first WEEKS of a project twiddling my thumbs waiting for a laptop, just to spend more weeks waiting on access to source code, tooling, etc.

My friends on the strategy side could start and finish entire projects in that time.

Your friends on the strategy side are the folks those clients think parachute in, drop a deck and convince execs to do things, and the disappear.

Not necessarily worse, but the stereotype fits! You are, at least, soon doing tangible things.

It's been over 20 years, but I used to build batch processing pipelines using SMTP (not Outlook). Biggest "choose your own adventure" aspect is accounting / auditing (making sure you didn't lose batches). I still joke about it as an option; although if somebody took me up on it I'd write up at least a semi-serious proposal.

In the middle are Mule, Rabbit, Kafka, ZMQ.

At the other end is UDP multicast, and I still use that for VM hosts or where I can trust the switch.