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.
Podden och tillhörande omslagsbild på den här sidan tillhör Steve Jones. Innehållet i podden är skapat av Steve Jones och inte av, eller tillsammans med, Poddtoppen.
