The newest *DD development trend: Panic Driven Development.

When your hexagonal domain driven serverless microservice architecture explodes in production and you don't know which one of the 50k components is failing.

Data Engineering cycle of hell:

1) Receive an "beyond urgent" request for a "quick and easy" "one time only" data need.

2) Do it fast using spaghetti code and manual platforms and methods.

3) Go do something else for a time period, until receiving the same request again accompanied by some excuse about "why we need it again just this once"

4) Repeat step 3 until this "only once" process is required to prevent the sun from collapsing into a black hole

5) Repeat steps 1 to 4 until it is impossible to maintain the clusterfuck of hundreds of "quick and simple" processes

6) Require time for refactoring just as a formality, managers will NEVER try to be more efficient if it means that they cannot respond to the latest request (it is called "Panic-Driven Development" or "Crappy Diem" principle)

7) GTFO and let the company collapse onto the next Data Engineering Atlas who happens to wander under the clusterfuck. May his pain end quickly.

Week 1 of the new job, and it seems I have some pretty low expectations to meet.

Seriously, I just did the math. Let's say one works an average of 48 hours per week, 50 weeks per year. Just as an average. That's 2400 hours in a year.
In the Micro-scale, a manager would mess up their team once every 2.4 hours (2h24m) or about 4 times per day (assuming 5 working days per week).
That is a pretty low bar to clear. It easy not to be an antsy brat that are-we-there-yet's a professional dev four fucking times a day.

And yet... that is what the complete moron who previously sat on my chair used to do.
Seriously, apparently he used to remote access the team's dev envs *while they were working* and even mess up some of their code. Just as a "monitoring measure". He logged their "keystroke time" in a day (using a primitive windowing method, I must add).
At least 7 requests for updates per person per day. I have his slack history, I checked. Dude literally did nothing else but be an annoying anxiety death pit.

And then there is his bulshit planning...
He created tasks out of his stupid whims, no team review or brainstorming, not even a fucking requisites tallying interview.
He prioritized those out-of-nowhere tasks using panic-driven-development practices and assigned them by availability heuristics.
No sizing method, just arbitrary deadlines for tasks.

I think I will need to have daily standup meetings and an open door policy (that is to say, do no actual work) for a couple months until I can instill some sense of autonomy on my new team. Shit.

Someone has another idea? How do I bring some confidence&autonomy back to devs that are used to be treated like dogs?!?

A word of advice:
If you integrate email verification very tightly in the registration flow, it will be a world of pain to implement changing the email address.
It's alright, I didn't want to do anything this afternoon anyway.

That awesome moment someone accidentally deleted all the Jenkins configs and you're just praying no critical bugs come up...