Months ago, I was updating slides for a Launch and Learn session on integration tests. One slide talks about developers having a local database, and I added a bullet point: developers should NEVER share databases.
I sent the updated slides to the Improver who was going to present the session with me. He mentioned he’d been pondering that exact topic, then decided not to send me his thoughts. But since we’d landed on the same idea, he shared anyway.
That got me thinking. What else have I been doing for so long that I’ve just accepted it? What practices have become so ingrained that I don’t even notice them anymore?
The Pull-the-Plug Test
The need for developers to work completely isolated crystallized for me during my years of heavy travel. I wanted to get work done on planes. That meant running everything on my laptop without any network access. Pull the plug, keep working.
Another case: a project where I couldn’t access or reproduce the client’s environment. That’s when I created an XML data service so I could run everything locally without touching the client’s infrastructure, which we could never reproduce anyway.
This pattern has paid off repeatedly. Azure outages a while back? Didn’t affect me. I could develop the application without accessing Azure B2C. The cyber attack that took down huge chunks of the internet for hours? Kept working. Power outages from hurricanes? Same thing.
If I can’t work without the network, something’s wrong with my setup.
What Else Am I Not Seeing?
So what other practices have become invisible to me?
Source control. Any kind of source control system. And for the last several years, a distributed one. I can’t imagine working without it, but I know plenty of teams still don’t use it consistently.
Automated tests. They’re just part of how I work for the last 20 years. Not a separate activity—just part of building software.
Constant refactoring. Code isn’t static. It evolves as I understand the problem better.
Understanding why before how. Having conversations to understand why something matters. Then, separating what we’re doing from how we’re doing it once we understand the why.
Sharing with the team. Lessons learned. Struggles. Things that worked. Things that didn’t. Not hoarding knowledge or pretending everything’s always smooth.
Isolating languages. I often call it the “Spanglish of programming.” T-SQL code embedded in C#. HTML inside JavaScript. JavaScript inside HTML. Mixing languages always creates confusion and complexity. Keep them separate.
The Shared Database Problem
Back to that bullet point about never sharing databases. It seems obvious to me now, but it wasn’t always.
When developers share a database, they can’t work independently. Someone changes a schema, and everyone’s broken. Someone adds test data, polluting everyone else’s environment. You can’t experiment freely. You can’t pull the plug.
It’s the same principle as the network dependency. If your ability to work depends on what someone else is doing, you’re stuck.
What Are You Not Seeing?
These practices aren’t universal. They’re not even common in many places. But they’ve become so fundamental to how I work that I forget they’re choices, not givens.
What have you been doing for so long that you’ve stopped noticing it? What would someone new to your team find surprising about how you work?
Maybe it’s worth writing those things down.
Leave a Reply