When you consider “my problem is solved this time” as documentation then a discord discussion can be considered good documentation. But If you want documentation as reference for everyone and don’t wan’t to repeat process/procedures every time some one needs it. It’s the worst platform for it. And For documentation we never want the first.

In this context email lists were the best of the best documentation ever.

I hate video links. The information could have been a few paragraphs of text that I could glance. Instead this much minutes of video that you can’t search, glance over, read while listening to something else… So it’s a pass for me.

I wouldn’t ever imagine to shed a tear for the processes I have killed in my whole life. I feel like a homicidal maniac.

First, persistency. You data lifecycle may not be directly proportional to your applications lifecycle. You may need it even after the app is shut down.

Second, RDBM systems provide a well defined memory/storage structure and API - “structured query language”. This enables you to easily query your data and acquire suitable views that are beneficial for your applications purposes.

Third, It’s always better to outsource your data layer to a battle tested, and trustworty database then trying to reinvent the wheel.

So this paves a road for you to focus on your business logic than splitting that focus for the data layer and business logic.

I see that the problem arises from the "visionary, but lower experienced newer developers (compared to the past generation) " trying to fix a world where “don’t touch it if it works crowd who has seen all old timers” built, by putting each layer over the older one. It has all the capabilities, but there is no “single vision”, no “well defined api”.

Old established paradigms are being broken. Some conventions are forgotten, new tooling and perspectives are being built.

Sure this means there is an unfortunate clash is happening.

I can’t say if this is a better, or wiser world or not, however I can only say this is the way now. You can adapt, try to embrace and push forward things or you can try to stay away and become one of the legendary Cobol developer crowd. We know they are there in the wild, but we can’t find them.

I suppose it’s “confusing perspective” worthy.

Then I hope it won’t get any traction.

I hope this is a joke and not intended to be real.

What? The? Fuck?

I want to see the 10x hamsters!

I was not expecting a rabbit hole that deep. Who underwrite that api for shipping?

I had no idea! Thank you for the great explanation.

West-sex wessex
South-sex sussex
East-sex essex but no
North-sex Nossex?

Shots fired! Shots fired!

Firefox even has tab sandboxes now. So you can even run personal aws on one tab and business aws in another. They will have their own sandboxes so won’t collide.

It is, but If you review 3 lines of pr and not the whole 50 lines of the file without thinking of the overall picture, this happens. I got this while reviewing a pr like this. And most probably I approved similar prs for this file in the past. Shame on me too…

Yep that’s on me:) let’s call this second breakfast!

It’s not the real issue. I introduced that while anonymizing the data. It’s that a 3-5 liner code became a huge switch case by just incrementing the code and never thinking how it should be done. This was caused by like 15 engineers in time :)

Something like below would be huge improvement:

subs1 = ["cluster1", "cluster2"]
if subs1.contains(clusterName) return subs1

And no reason to state this is from production.

no one looks behind and questions how and why.