Treat the running procss like a hot potato. You want to minimize how much time the process spends in your function to minimize hitting any landmines. The longer something lives, the more errors accumulate.
Returning early lends itself well to minimizing nesting. Instead of handling a success condition in a nested if statement. Return early or throw an exception early for an error condition so you don't have to nest the success condition at all. Nested code is harder to read and by nature more complicated than small simple if conditions. The top of a f
You start building functions where the top of the function is mostly error checking/validation. And the bottom of the function can only be hit once passing through all your internal checks. The running code is the potato and you want to hold on to it as little as possible
#Bugs
The longer something lives, the more errors accumulate over time. Just like life itself things to periodically refreshed to clear out the cruft has that has built up. Like reinstalling windows, or just restarting your computer. Programs are similar. Writing web services are nice because the requsets only live for a short period of time.
We had a line of code to get priorties for orders. It worked great in production. Except that it was missing a filter and was pulling thousands of orders. We noticed it was a problem when it started blocking another job from running. How would we have detected this earlier? Unit and integration tests would of passed. We would of need some kind of CI/test framework that also recorded the total DB reads of a method and check that they didn't exceed some maximum or fall 'out of family.'