I caught this piece on the need for programmers (developers) to not trust anyone, including themselves. It is written by a software developer for other software developers, but I think it can also apply to database work as well. It is a bit long, but it starts with the nature of abstractions in the world and how they let us work with simpler models of a situation or environment. However, most abstractions are leaky, and our assumptions about them can cause our systems to fail.

The leap from trust to abstractions seems a bit funny, but it makes some sense. We ought to simplify our situations so that we can generalize how to solve them, but we also need to verify things. There are a few examples, one of which is we ought to use tests to ensure the code does what we think it does, including using a wide variety of data. We ought to ensure that refactoring something doesn't break the system, or more often for databases, we return the same results. Changing a query to run more efficiently with joins or a window function instead of a loop or subquery should return the same results. Not just for one row but all rows, and across different inputs.

One I especially like is the check on deployments. If we changed our code and had a deployment, did our code actually get deployed? In today's world where different people might be responsible for merging and deploying code than those writing the software, we might want to verify that our changes actually got deployed. Perhaps reviewing deployment reports or logs can help ensure that we know the state of our live systems in addition to those in development.

There are some suggestions for how to become a better software developer, and as you might guess, this requires learning. I think in today's world, some group exercises (katas) or reviews can be helpful as well. Maybe even practicing new techniques in a sandbox and running them through a PR process to let others see them. It can be scary to ask others to review your code when you are learning, but they might teach you something, or you might teach them something. We build in teams; we should think about learning in teams, at least periodically.

Becoming a successful software professional, data or application, takes regular work to improve our skills. Just as a woodworker might practice with their tools or a chef with recipes, we ought to practice with our tools. I'd hope that many organizations would also see this as something that needs to be encouraged with some amount of time allocated towards ensuring your staff continues to improve and produces high-quality results.