frontend expects the backend to return errors, but the backend lies and says everything was successful, and then certain things break in the UI
That’s a double failure then: not only does the backend do it wrong, the frontend devs don’t even know it. If they’d agreed on one way of handling it, they’d still be able to work it out. But if the devs don’t even communicate their standards with each other and the frontend devs obviously don’t know about the problem…
devs love to argue abt this shit
Devs and standards have a contentious relationship.
If I develop something, I obviously know what works best for me, so I don’t want to be constrained by some dumb standard. If someone else doesn’t follow them and it makes things harder for me, they’re a clueless fuckwit that shouldn’t be allowed near a computer ever again.
Yes, that’s a double standard: I don’t even have a standard when it comes to handling standards.
The main difference being that code is typically stored in plain text files, where you can more easily compare and merge differences, while some other document types are harder to diff usefully. That doesn’t mean you can’t use git to keep their version history, it just means resolving merge conflicts might be a bitch.
This is really damn good. Thanks for sharing it!
Technically, I’m not new, just recently moved instance, but maybe mine delights you anyway? Assuming it’s still there, idk how long it lasts.
How is this getting even worse still? Why would a single endpoint work differently? That suggests they have standards, just one arsehole decided to shit on it and the rest didn’t vet their code enough to catch the issue.
I worked QA in a small dev team for two years. You might be surprised how uncomfortable you can make some developers within five minutes of “basic testing”. By the time I left, the team lead loved me as much as some of the devs must have hated me.