I thought we agreed those were one and the same.
You don’t need a second pair of eyes. But you do need to follow along in what happens, observing the operations carried out while comparing to what you meant.
To observe something is to obtain information about it, to make measurements.
Ask jim to tell you what he’s doing for each thing he does, that’ll give you enough information about where jim stopped making pizza and started making burgers that you’ll be able tell jim what adjustments to make.
So for example. Are you executing an instruction that says append? How many iterations happen? Are there conditions involved, what do those conditions evaluate to, and so on.
What length does your list have? If you iterate through that list, how many iterations should that therefore be?
You can test that.
for thing in menu:
how many times should/does that say hi?
You’re the one writing the code. Nothing in it is hidden from you, you decide how it behaves, you make it emit whatever information you’re looking for. You can test things you can change things you can print things.
How do you think I’d figure it out?
Well, I read the code, I suppose in some sense I’m better accustomed to correctly interpreting at least simple things in a way that would make me run into the mistake. But if that wasn’t enough (reasonable) then I would start looking at what was carried out.
You should in general expect to be able to fix any code you write.
It’s not about a second pair of eyes.
It’s not about being lucky or good and getting it right.
Dig in. Find out what happened.