Parent made it sound - to me - that you put an input in and hope for the best. If you understand the operators, you can quite confidently predict an output given an input.
That’s the point. In an imperative language if you don’t yet understand (or make a typo, or whatever), you can just print/console.log and find out.
I’ve seen junior devs, data analysts, and LLMs spin their wheels trying to figure out why adding a join isn’t producing the output they want. I don’t think they would figure it out using SQL alone if you gave them a month.
The equivalent of `print`/`console.log` in SQL would be using subqueries/CTE and run them to see the intermediate result (just like `print`/`console.log` show you intermediate results of the executions in an imperative language).
Then you back off, and go back to first principles. Create the minimum example of the problem, and as a sibling comment mentioned, break it down to its constituent parts and observe what happens in each.
Depending on how you write your query and how you structure your data, a query can take 0.005 seconds or 500 seconds.
SQL hiding the execution is an extremely leaky abstraction. To get the performance you need, you have to plan your possible queries in advance together with how to structure the data.
I mean, it doesn't matter if you only have 100 rows per table, but once you're dealing with multiple tables with millions of rows each it's everything.