Sometimes, I can be too clever for myself. My future self that is.

Fancy queries that do everything I need can be satisfying to write, but sometimes the tradeoff is complexity in the query that makes it difficult to understand and update as needed. Then if you have many levels of these nested clever queries and you start intertwining them together to do different things, this can lead to a catastrophic meltdown when a basic assumption of the system changes. Like let’s say the customer all of a sudden wants decimal points in an identification number that was was always an integer before?

Granted, your system has to be built on assumptions. In fact, building in more flexibility also leads to complexity. That’s why it’s wise NOT to add little stubs to your code for “future improvements”. Only generalize to the point you need to. Try not to be clever in using assumptions about data types to take shortcuts and depend on special undocumented behaviors that kind of look like bugs. They might actually get fixed some day.

I suggest trying to use functions and subs that do one thing with descriptive names. For more complex functions, use one or two sub functions to get the behavior you want rather than giant overarching functions. Try to decouple your business logic from the SQL and even form behaviors. To do all this, you just keep coding the best you can and learning as you go. One of my best teachers has been my past mistakes!

May your code be simple and easy to maintain and change. Go and make the world better!