Comment by cratermoon 2 days ago
I loathe working places where they just give you all the permissions because it's "easier". One risk is if something does happen, and they don't have exceptional tracing and logging, (and let's be honest, at an organization sloppy enough to hand out privileges like candy, what's the chance of that?) it's difficult or impossible to pin down the source to any individual. As a result, both responsibility and suspicion is diffuse.
I have so many horror stories from there.
When they did decide to lock down the database, the DB admin only locked in down in the sql server client most people used. If you used some other client, you still had access. _sigh_
A second thought. It leads to lazy application development. Whenever you have production intervention that happens more than a few times, you should just make a feature that does it safely via application code.
I've definitely worked in places where "Move fast and break things" tended to focus on breaking things. There would be bugs that we didn't fix because "We can just fix the database when it happens." It would take 2hours to fix a bug that would cause of 10's of hours of weekly support request, but the focus would always be on building new features, of which 10% got any real usage.
Meta completely restricted graph data access to requiring a specific business purpose and managerial approval tied an articulable, concrete task need.
The appropriate restrictions are relative to the size and momentum of the organization. It's easy to spend months setting up safeguards rather than working on product development that won't proportionally return.
Of course, this involves being honest with yourself about risk and reward, and we all have implicit incentives to disregard the risk until we get burned and learn to factor that in.