It doesn't seem to be that straight forward, though, given multiple menu buttons all point towards a single button. For example: 0, 4, and 6 all move leftwards to 1, which seems to imply the menu looks more like pic related. It'd be interesting to see what menu this code is actually for.
View attachment 7608169
This is interesting, because, like, I can see the logical throughline there, but if I were in his position, I'd probably still insist on trying to make something more beautiful and scalable, maybe something that checks the actual 2D space in the cardinal direction selected from the center or origin point of the selected button, breaking exact ties with preference to the higher index of those selected, etc, if for nothing else but because I like coding. If you resent what you do, that resentment will bleed into the work you produce, and here's a great example.
It might be a bit more work up front, but I dunno, I like playing with that sort of logic more, and then you'd have a system that scales into anything you care to throw at it after that point, rather than having to build a button selection dictionary for each visual interface. Plus, building one rock-solid logical implementation for all cases to infer from means you won't have to debug individual implementations where you fuck up, have to recheck the data, change some numbers, try again, etc. It also opens up more technical potential - for instance, then you could have selection screens that are dynamically-assembled, since you're doing a runtime assessment of the data, rather than using hardcoded instructions.
I could see someone disagreeing with me on that point, though, if they math out that it's less total coding time.