• Assert Transformations in Azure Data Factory
• DevOps 101 Webinar: Key Concepts and Terminologies
• Raising Exceptions and Error Handling with SQL Server THROW
• From the SQL Server Central Blogs - How to use Azure Site Recovery (ASR) to replicate a Windows Server Failover Cluster (WSFC) that uses SIOS DataKeeper for cluster storage
• From the SQL Server Central Blogs - Comments in your generated code : T-SQL Tuesday #155

• The Delete Order

Daily Coping Tip

Find joy in tackling something that you have put off

I also have a thread at SQLServerCentral dealing with coping mechanisms and resources. Feel free to participate.

For many of you out there working in a new way, I'm including a thought of the day on how to cope in this challenging time from The Action for Happiness Coping Calendar. My items will be on my blog, feel free to share yours.

Good Enough

I find that many of us that work in technology want a solution to be great. Often perfect. Computers are so good at following instructions that we expect them to work as we intend all the time. We aim for being perfect in our code and we find “good enough” to be a low bar.

I think this is because many times something barely works and gets deployed because it’s good enough. Maybe the code can’t handle a load or corner cases and that’s caused us some sort of stress of pain. So we don’t want good enough. because we've been burned in the past, either by our code or someone else's.

However, good enough means to me that it is good enough for most situations. It’s not leaving something unfinished or undone, but finishing something that works well. I often tackle chores in this manner, usually because of time crunches. I consider the performance impacts, but in a realistic sense. Not all of my code will be accessed by thousands of users trying to process millions of rows. There are plenty of systems where we know the code will be thousands of rows and dozens of users. We should write the best code we can, and spend time improving our coding skills over time, but we don't need to over-engineer code too early.

At the same time, we should not be satisfied with code that we think will not meet the needs of our customers. Whether in function or performance. Sometimes we make quick decisions, knowing we will need to rework the code. In that case, we need to allocate time, file a bug ourselves, or something else to ensure we revisit this code. That has been the case often with some administrative code that I need to run today, but I know this will need to be run regularly over time. I might shortcut code with a cursor or loop, but plan on finding a better solution that performs better and is more robust. If can be automated, includes error handling,, logging, and more.

Life is a series of trade-offs. I rarely get something done as perfectly as I'd like, but that doesn't stop me from trying to be better over time. I can chase perfection, especially in code. If I regularly learn and change how I code, I find that my "good enough" becomes better and better every month.

Steve Jones - SSC Editor

Join the debate, and respond to today's editorial on the forums