I worked at a place where only certain teams with a dedicated DBA were trusted to write direct queries (based on past incidents). All other teams had to ask a central DBA team to build stored procedures for any interaction with the database. If you think that this would create a huge backlog, you are correct... Non critical updates also needed to be coordinated with a "release train" where the code had to be ready 2 weeks before deployment due to the amount of testing it required. It was one of the major drivers behind an initiative to create micro services with separate databases that each team could do what they wanted with.
We ended up with a huge number of micro services and special orchestrator services to handle distributed transactions. But I guess that in a company of that scale, there are no perfect solution. At least we were able to make changes within minutes/hours instead of weeks.
Paradoxically we also got more pressure to deliver. In the past it was acceptable to leave a healthy buffer at the end of the scrum, to avoid missing the release train. This meant that we often spent the remaining buffer on refactoring, fixing small bugs that we felt we had time for or experimenting with POCs.
It sounds like you have ended up in a bad situation. There's no real suggestion I can provide for how you can improve your situation, other than to try to find a way to disconnect. (Meetups, walking, museums, hobbies).
Maybe that means talking to a professional therapist to find out how you can handle the situation. They get paid to help you, and there is no shame in that
It sounds like a toxic workplace, but you should do yourself a big favor and try to put that behind you. If you keep that mindset in your new job, your perspective will be negative and you risk burning out.
If you work at a traditional workplace, think of yourself as a professional. Do the best work you can during business hours, without ruining your health. The company is paying you to make decisions that are best for them, and you may not like it but that is what you agreed to. At the same time, they only pay for your work and not your soul. You need to keep a balance between work and you as a person.
Unfortunately there are many toxic workplaces out there, and if I ended up "trapped" with no escape, I would probably consider things differently. But when you finally escape, keep an open mind and try to put your bad experiences behind you.
I was one of the first employees in a startup, and if I hadn't made compromises the company would probably not exist today. Your approach only works for big established companies where your team has limited impact on the results.
For small and medium sized companies you definitely need to make compromises. It is part of your job as a professional to make choices that leads to the best business outcome.
Unfortunately a lot of developers don't have a connection to the business side, because they are "protected" by several layers of management, PMs and designers that interact with the business on their behalf.
Getting a product out quickly means that you also get feedback earlier. This is not only good for business, but it is also an opportunity to evaluate your implementation to see if it matches your assumptions. In my experience this causes less stress compared to rolling out a "perfect" solution that has to be rewritten while under pressure.
My job as a developer at my current workplace is to reduce complexity and get the PM and designers to cut down their initial plans to a minimum. It makes arbitrary deadlines less stressful and any delays will not have the same impact.
We ended up with a huge number of micro services and special orchestrator services to handle distributed transactions. But I guess that in a company of that scale, there are no perfect solution. At least we were able to make changes within minutes/hours instead of weeks.
Paradoxically we also got more pressure to deliver. In the past it was acceptable to leave a healthy buffer at the end of the scrum, to avoid missing the release train. This meant that we often spent the remaining buffer on refactoring, fixing small bugs that we felt we had time for or experimenting with POCs.