> Investigate problems and repair live data, usually just by logging in as a user and using the tools in the product. Can they do this themselves? Sure. Do they appreciate our doing it instead? Oh, hell yes.
This is definitely one that doesn’t scale as eventually they don’t allow devs to see prod data, so using user accounts is a no go at my org for that reason.
Makes things infuriating for both clients and customer support.
Not being allowed to see production data (or even in some cases see production!) was my greatest frustration in my last corporate job. But to be fair, keeping engineers off the live data was…pretty non-negotiable at most customers.
Which leads to some pretty boring days onsite, when “onsite” means “in the SCIF”
Though there's a big sliding scale there, between "not allowed to look at prod user data for privacy/etc reasons" and "the giant black hole of nothing-comes-out" in a SCIF.
If “devs” can’t have access to production data then they can’t be responsible for production issues, simple as.
I would say 95% of my intellectual horsepower at work goes into queries and analysis of production data tables, event streams, and logs to investigate issues or confirm key invariants are holding. Production is infinitely more creative than anyone sitting down to write unit tests. Organizations refusing to learn from it, as a matter of policy, either have incredible confidence in their testing and formal verification regimes… or much more likely don’t give a shit about correctness.
This is definitely one that doesn’t scale as eventually they don’t allow devs to see prod data, so using user accounts is a no go at my org for that reason.
Makes things infuriating for both clients and customer support.