If it's taking days to find the problem, then you're probably doing something wrong. Learn from the experience, and improve your process.

Version control. Use it. Commit often. Work on a single feature at a time within any given branch. Use version history to quickly diagnose when a bug was introduced (either by inspection, or by bisection testing for it).

Tests. Write them. Unit tests are the simplest starting place, and will immediately help you diagnose when your code isn't even meeting your requirements for the desired use-case. Unit tests also make it easy to fix bugs, as you can practice TDD (test driven design) for bug fixes by introducing a test case that reproduces the problem -> fixing the problem -> success.

Tests. Build them. There's a lot of things in games that are easier to visualize than code. Have a test level that can contain a test layout for every single feature in the game. Have a spot to test the jump, the long-jump, the bouncy shot, the target tracking shot, etc. etc. etc.. Go there often, and make sure everything still works, and every new thing works as intended in isolation.

Tests. Record them. Sometimes things are hard to reproduce. Build you game with deterministic replay capability. Always record your inputs while playing, and have a mode to play them back. Here's a good GDC video for Retro City Rampage talking about how useful this technique is. This lets you easily reproduce bugs from yourself and from your testers.

Tests. Diff them. For visual systems, build a screenshot diffing tool. Using #4 as a starting point, capture screenshots every X frames. If those screenshots differ from your "golden" captures, then you broke something.

Tests. Smoke them. A "smoke test" is a test where you leave the game doing something all night (or on some kinda fast-forward) to make sure things still work in 24hrs. This is really important for things like open-world games with no loading screens which are going to be played for many hours in a stretch. Sometimes things creep up in the background over time (memory leaks, floating point errors, broken timers, etc.), and you wouldn't normally see them in your short REPL cycle of development.

Version control. Use presubmit checks against all the tests you just wrote. Keep yourself and others from commiting broken code to the repository.