Shell scripts fail in ways that look unrelated to the code: a command runs in the wrong folder, a variable is empty, a glob matched nothing. The shell can tell you which of those it did, if you ask it to, and that trace is usually the whole answer.
About 1 min of reading
Trace a failing script.
Write a script with a bug
Before you run it, say out loud what it will print. Then open the answer.
Run in an empty folder
Before you run it, say out loud what it will print. Then open the answer.
Trace it
Before you run it, say out loud what it will print. Then open the answer.
Most mysterious shell bugs are word splitting or globbing on a value you did not expect. Quoting every expansion removes that family of bugs, and the remaining failures are real logic you can read.
Run the script against three files rather than three thousand. A bug that shows on three is the same bug, and the run takes a second instead of a minute and a half of unreadable output.
Running the script in trace mode prints each command after expansion, with its status. You see the actual arguments, so an empty variable or a bad glob is visible rather than guessed at.
A script that stops on the first failing command tells you where it broke. Without that, the failure is somewhere earlier than the message and you search the whole file.
Echo the expanded line before running it. When the line you see is not the line you meant, the bug is in the data reaching it, not in the logic around it.
Each one is defined here on this site. Open the entry for the full definition and the other words it points at.