Thanks for the answer! What you’re saying seems to be true, but it wasn’t given in the instructions, so I guess you were supposed to figure out that this was the case. It seems this was true for everyone, so it wasn’t just me that got lucky. I got confused by my assertion failing on the example, because the second path reaches the goal in three steps which is not a multiple of the instruction length (2). This never happens with the real data. The example wraps around neatly at 6 instead, so just removing the assertion makes my code work on the example too.

It sounds like you have the mindset that you have to learn programming before you start doing it. Which is especially hard today as there’s so much information, so much to learn, so many tutorials to watch. There’s always something to learn. Don’t expect to reach a point when you “know” programming.

Instead try this: Stop practicing and start programming. Start with a project that you want to do, for whatever reason. Some small utility, a really tiny game, a joke program, whatever that gets you to focus on creating something rather than learning something. You will learn the things you have to learn in order to progress on the project. This is completely normal, and a good skill to have, even for professional programmers.

I use it from time to time. Often I test manually instead of automatic, and it often works very well.

But if you want a story about an unconventional use of git bisect, I think there’s one about the time I had a directory with lots of files, and one of those files was causing some problem, but I didn’t know which one it was. Those files were not under version control, but I created a repo with them, where each file was added in a separate commit. Then I could use git bisect to find which file was causing the problems.

Also relevant xkcd