Environments and People

Engineers and managers alike blame shared non-production environments for flaky tests and slow feedback, but the article argues that the environment is a symptom of deeper cultural and process problems. Bad habits like hard-coded IDs, manual state injection, and ad-hoc use of shared servers corrupt the very purpose of those environments. The piece shows that simply adding another env never solves the underlying issues.\n\nConcrete anti-patterns are described: hard-coded database IDs that cause intermittent failures, lazy reuse of shared Jenkins jobs that break CI pipelines, and developers hijacking staging servers with feature branches. These practices illustrate how lack of isolation and automation makes shared environments a liability rather than an asset.\n\nThe solution stack focuses on three practical levers. First, automate every test and ensure each run is isolated, using containers or local stacks like LocalStack to mock cloud services. Second, build explicit testing interfaces or APIs on services so state can be induced without touching production-like environments. Third, treat shared environments as immutable sandboxes that no one manually modifies; all changes flow through CI pipelines.\n\nBeyond tooling, the article stresses a cultural shift: managers must surface and correct bad behaviors in retrospectives, and teams should prioritize cheap, local testing over expensive shared setups. Training managers to recognize and address these patterns, and reinforcing a "do not touch dev envs" rule, creates a feedback loop that reduces waste and improves reliability.\n\nWhen teams adopt automation, isolation, and a testing-first mindset, they stop creating more environments as a band-aid and instead build faster, more dependable delivery pipelines that scale without the usual pain points.