* start logging shit, even things you know to be true / can't possibly be the problem. Somewhere your model of the code is broken, and you need to test find the breakage (model needs correction, or program needs correction).
* Split the problem space. Payment messages are not getting to the slack channel. Well, is it a bug in receiving payments, or a bug sending slack messages? Check if the payments are hitting the database. If no, you know it's on the input side. If yes, you know it's on the output side.
* Explain the problem to someone else; if you're alone write it up like a question you're going to post on a forum, with as much detail as possible. This must engage a different part of the brain, because often I'll figure out the issue while writing it up I'll reveal some clue while logging example output to add to the post.
Longer-term, teach a programming class! You'll get very good at debugging issues because you'll encounter a lot of other people's bugs, and you'll get a feel for what causes particular failures.
Also, don't feel any shame in asking others for help. Even senior devs get blocked, and they ask other seniors, or juniors, or if juniors are not available a rubber duck will suffice.
I forgot one - if you start thinking there's a bug in a library, reduce your code to the smallest example that reproduces the problem. If you get it down to 5-6 lines you're going to either (1) remove something along the way that fixes the problem and gives you a clue or (2) you will have something you can post in message boards when you ask for help.
You'll also have a shortlist of functions that you can search for in stack overflow, and compare you example to theirs.
>Somewhere your model of the code is broken, and you need to test find the breakage (model needs correction, or program needs correction).
Most of the harder bugs I run into fall into this category. Great list of techniques to use. For when I'm really stumped I go into a more formal scientific method to the splitting the problem space approach. Formulate a hypothesis that if answered will reduce the search space, either by ruling in or ruling out things. Write it down - this is the important part, test it, repeat.
It's slow but usually helps me keep forward momentum. Worst case it at least creates a list of things that need better logging to figure out what's going on
+1 to this. Make ZERO assumptions about the problem, and observe everything you reasonably can. In the increasingly (?) service-oriented architecture world, that includes fundamentals on your platform (i.e. I recall the first time I root-caused an issue that turned out to be an AWS bug) and taking the time to monitor external dependency changes (i.e. a service change, a code push, someone reverting stuff, etc.)
I also can't agree more with no shame in asking others. I would go as far as to say if you aren't asking others, you are going down a dangerous path of assuming you can solve the world's problems by yourself.
* Split the problem space. Payment messages are not getting to the slack channel. Well, is it a bug in receiving payments, or a bug sending slack messages? Check if the payments are hitting the database. If no, you know it's on the input side. If yes, you know it's on the output side.
* Explain the problem to someone else; if you're alone write it up like a question you're going to post on a forum, with as much detail as possible. This must engage a different part of the brain, because often I'll figure out the issue while writing it up I'll reveal some clue while logging example output to add to the post.
Longer-term, teach a programming class! You'll get very good at debugging issues because you'll encounter a lot of other people's bugs, and you'll get a feel for what causes particular failures.
Also, don't feel any shame in asking others for help. Even senior devs get blocked, and they ask other seniors, or juniors, or if juniors are not available a rubber duck will suffice.