How do professional programmers find logic efficiently?

Ex post facto, it's hard. It helps to try to mitigate them before they become a problem. One way to do that is write more unit tests; that way, you can be more confident that the individual pieces are free of logic errors before you integrate everything.

The best general advice is probably to repeatedly break problems into sub-problems. If the whole thing fails but the first half is okay then the problem must be in the second half, and so on.

Another tip: learn to use a debugger fluently. Debugging does not always require a debugger, but there are many times when a debugger will be the "winning choice" that helps you find the issue faster. Other advice already given can be combined with my advice to use a debugger. For example, by breaking a problem into sub-problems (and smaller functions), you will have many good options (many functions) in which to set a breakpoint in the debugger and check incremental values. And by having unit tests, you might sometimes run the tests in a debugger as well. Since you mention python, learn pdb. Skills in one debugger will translate to almost all other debuggers. I mastered gdb long before I needed python and pdb, but because I knew gdb, it was trivial for me to become productive in pdb. If you're into books, consider "Why Programs Fail: A Guide to Systematic Debugging" by Andreas Zeller. A lot of the examples in the book look a bit like "toy code," but the tactics that the book encourages are "production grade tactics" (even if the example code does not look like production code).

One key to debugging is defining the problem and noticing what actually happens. Simply declaring that "it does work" or "it's failing" does not get you closer to a solution. Instead of a negative observation (which is actually an expectation), e.g. the "LED does not blink", you need to also observe what does happen without the negative condition, e.g. "LED stays off" or "LED stays on".

Instead of explicit debugging while executing the code, a code review or desk-checking the code can be useful. Admittedly this can require more skill and/understanding of programming and logic one might possess. But knowing that there is a problem somewhere in the code should make you more critical of that code and deserves (another) analytical look.

Try to avoid creating bugs in the first place. Instead of letting bugs creep into your code, from the get-go you can program defensively. Add code to validate the parameters used in a function. Try to make sure that boundary conditions and corner cases are always properly handled. For large programs, I prefer to start by coding and testing with just a skeletal version or bare-minimal framework of what needs to be accomplished. Then add functional pieces or layers which gradually increases complexity but also repeatedly retests what was implemented under fresh circumstances.

Always be cognizant of what "facts" you are assuming versus what you actually know backed up with specific (and current) evidence/experience. Always be willing/prepared to test those assumptions, especially when any problem arises.

Think a lot harder before you start writing any code.