You might be asking the wrong question, or have been slightly misled by the reply you mention.
Afraid I am not particularly up on my 3ds ROM hacking/emulation/debugging but have done enough of it on older systems that I can give a general overview, and some notes on where the 3ds might change up from older stuff that most spend their time contemplating.
Traditionally most people use emulators when they can get them for the device they care about to find cheats.
https://web.archive.org/web/20080309104350/http://etk.scener.org/?op=tutorial is my usual suggestion for a link on basic cheat finding, albeit for the GBA. The 3ds (and basically everything else) does work in much the same way, however with the 3ds being a bit newer then there are a few quirks with memory arrangements and the way the code works means it might not be in the same place between runs (see pointers).
If emulators are not yet a thing for your device then some kind of hardware access is needed, with such things being known as a debugger (though it is not the only sort, even if technically it has much of the same abilities). These will allow you to fiddle with memory on hardware (including dump it to compare), and some abilities to mess with the code as it is running too though what ones you get might vary.
You can do an awful lot with basic memory manipulation (it is well within reason to have infinite consumables for a game, moon jump, max stats, all unlocks, walk on water maybe, walk though walls is a possibility, inventory cheats, cheats to do things like if this then do that), however a debugger will allow you to play with the code as it runs rather than just the memory. This opens a lot more doors.
Memory is just memory really, it holds data the game uses. Play with a debugger and you can change how the whole game operates from the ground up -- rather than just infinite health you never get hit (no knockback, stun...), can change what percentages something will happen or force outcomes to decisions the game makes and much much more.
The trouble comes in that rather than memory which you can generally understand pretty easily and quickly for most things (it is usually a value or a flag and that is pretty much the end of it. There are some things like understanding why double jump flags are good for moon jump, or why you might want to look at various stats if the game does not have it, or why you would want to first get infinite basic potions or something you can buy in the shop before you move sideways in memory and make it so you can have infinite end game sword only available as a rare drop in a 20 hour sidequest) you instead have assembly.
Assembly is what the CPU itself runs with. It is a selection of short (in the case of ARM, which is what the 3ds runs, mathematical/electrical/programming operations and sometimes less complicated (which is not necessarily a good thing) than a PC.
Afraid I don't really have a good learning ARM assembly, much less the 3ds type.
I usually link
https://www.plantation-productions.com/Webster/ and
https://stuff.pypt.lt/ggt80x86a/asm1.htm for the PC and that gives people a reasonable grounding.
I have stuff for some ARM processors like the GBA
http://www.coranac.com/tonc/text/asm.htm and the staple of GBA and DS hacking
http://problemkaputt.de/gbatek.htm#3dsreference is starting to get some 3ds info,
https://www.3dbrew.org/wiki/Main_Page has a bunch of info.
There will be three main classes of debugger, maybe four if you count some aspects of homebrew and commercial development which you likely will not have here (that being debug flags enabled).
1) The in hardware stuff we spoke of earlier. Here you will probably have either a hardware device attached to the machine, or as the 3ds is a modern device with a firmware running at all times and wifi you can get stuff done there.
2) A specialist emulator with debugging functionality. Not all emulators will have this, and sometimes you might have to run an extra program (if you see GDB mentioned then this is one such things -- guess what the db in that name stands for?) on top of things.
Afraid I have not really kept up on 3ds emulation.
3) A standalone debugger that will be able to do static analysis, though you might be able to give it a boost with some data grabbed from an emulator or real hardware.
Ghidra is one such example, most know it more for the PC but there should be some ARM stuff/modules somewhere out there (ARM is also used in phones and tablets a lot so would be hackers are quite interested in it).
IDA is another such one.
Radare2 is one more.
If you want to go more basic then a basic disassembler (which is a key feature of any debugger really) should be available for the 3ds' particular CPU.
Most ROM hackers and cheat makers will spend their time with 2) if it is available and reasonably good as it is the quickest and easiest way to do most things cheat making cares about -- 1) is just tedious to use but has the bonus of being on hardware rather than inaccurate emulation and 3) is good for massive understanding of things but lacks info from hardware.
Anyway an example of why it might be good vs other things.
So you want to do a moon jump cheat. OK you might be a half bright cheat maker that knows about double jump flags (if you have a double jump it will have to note if a double jump has been done, find where it stores this "jump done", which if you can't always add and subtract things like you might boring potions and only have the one chance each jump is not necessarily that easy), or maybe you reckon that a gravity stat somewhere in the game, or a speed stat might influence jump height...
Rather than mess around with that the would be debugger/assembly versed hacker would instead likely note that jumping influences the position on screen and such things tend to have a dedicated hardware location (if 2d graphics see OAM, for 3d graphics then might be more of a virtual location, though 2d virtual location is also a thing some games have). Set the debugger to tell you when this location data is changed, jump at your leisure and it will flash up saying something changed it. While you don't necessarily care about the position the sound, the animations, the hitbox... all will be being changed within the same section of code that just changed the location. No messing around with savestates or hard to track down flags, you are right there watching the game make the decisions.
Or maybe they will note that jumping happens after you press A so they wait and see what reads the control state and follow that down.
Some debugging emulators, though usually for older systems (here is one for a NES emulator,
http://fceux.com/web/help/TraceLogger.html though know that FCEUX usually represents the gold standard for non PC debuggers and most things struggle to live up to it), will also have an elimination function. Here you get to a point in the game, start a elimination session and do everything but jump (idle, walk around, open menu...), say wait for a new function and now jump. As the game will have seen clock happen, idle animations, walk animations and whatever else then the new thing it has not seen will likely be the jump aspect.
Anyway now you can do many things to the jump command as you found it, including making it say normally jump double the height and still leave the double jump intact rather than abuse it (or potentially suffer the negatives of such things like hard to control).
I already mentioned detecting hits itself, and not just forcing things in inventory but understanding how things work,
https://www.dragonflycave.com/mechanics/gen-i-capturing is the sort of thing you might be able to write if you get a handle on assembly level fiddling, you can make it play different songs in the game, if it is one of those annoying games with anti cheat then you can see how it works in action rather than having to bash your head against memory dumps until you see the method it uses, you can figure out how save games are checked and work around it, and... actually now we are heading into ROM hacking proper.
https://gbatemp.net/threads/gbatemp-rom-hacking-documentation-project-new-2016-edition-out.73394/ if you are interested in that sort of thing.
