Recently I was pouring over a few questions in the forums and noticed something that I would think is obvious, but apparently it isn't so for other people. A poster was attempting to run a query across multiple databases and needed help structuring code to work in the context of each database. The poster was going back and forth a few times with others that were attempting to help them, struggling to get suggestions implemented into their code. That's typical, as someone that needs an answer often doesn't understand the solution and is learning. In this case, I found that the original poster was losing some of their troubleshooting skills in the process.

Years ago I read a piece on Simple Talk from Kathi Kellenberger. She is now the current editor of the site, but at that time she was just a SQL Server MVP and expert that was looking to help others learn more. The article was called Solving Complex T-SQL Problems, Step by Step, and it stuck with me. There wasn't any knowledge that I didn't know, but it was an organized explanation of the Kathi's steps that I found refreshing. This was a nice reminder to me to not move too fast, but ensure that I really understand what the problem is and work in stages.

I've certainly been guilty at times of moving too fast and glossing over some details. That might be fine in some cases, but if I produce code that's doing that, likely I (or someone else) is going to be rewriting code later. That's not what we want to do, especially if this is a logical error. I might understand some less than optimal code from a performance perspective, but there shouldn't be logical errors.

In this case, the poster had incorporated some changes into code and kept running the entire script, getting bad results. They even started to pinpoint a few areas where data wasn't correctly being returned, but couldn't solve the issue. This was a somewhat complex script, and it could be easy to miss some mistakes. This was also a dynamic SQL script, which often means that we have to extrapolate from our code to understand what the engine will actually execute. There's often a simple solution to help you break the problem down: use PRINT.

I've done this for most of my career, in many languages. Even today, I sometimes use this in PoSh to ensure that I'm not missing something being done. Watch windows and other debugging tools are great, but they sometimes are more difficult to understand when there are long strings of data. Print often simplifies the process.

No matter what tools, languages, problems, etc. you are working on, breaking things down is often the best way to tackle a complex task. You might be surprised how much clarity this can bring to a tough problem. Even if you need to ask for help, having a list of things you've tried, and some data on the results is very much appreciated by those you ask. That way they know what you've tried and what to recommend.