Pointers are things programs can use to keep track of where things are. Most programs on any device will have pointers but if they are static locations then it does not matter so much for cheat making, when they become dynamic locations (changes between boots, sometimes between parts of the game) then you get to pay attention.
Some games will use them as an anti cheat measure. A value that can be in one of many places is rather harder to find by the convention "use a potion, scan, use a potion, scan... method as taught in
https://web.archive.org/web/20080309104350/http://etk.scener.org/?op=tutorial and most other cheat searching guides).
Some programming languages will cause them to be a thing commonly seen -- generally for a program you are going to want to allocate some memory so another part of it does not come along, go "ooh free memory, *writes*" and mess things up. Once you are done you tend to return the memory or you end up with a memory leak. If different parts of the game fire up at different times (say you go to the options menu before you start a new game and it still has something running) then it might not be in the same location as it was a few seconds ago/last boot/earlier in the game/...
It was not common on most systems up to and including the DS (though there are plenty of examples of them on the DS), especially the older stuff where a programmer would be handling the locations of things rather than a compiler (that is one of the benefits of C over assembly -- you don't have to keep track of where everything is as the compiler will figure out where to stash things and how much space to assign each one). The 3ds went one further and the languages it can sensibly use (so the devs making games for it did, was a bit harder ask for the GBA or DS as they did not have enough power) make extensive use of pointers and programming styles that see such things be common.
Some aspects of it also apply to a type of security (see ASLR) that just happens at console level.
You can have pointers to pointers to pointers to... indeed if you are learning programming then in many courses for the final exam will get you to figure out what goes for some kind of pointer structure 20 something deep with the things and related concepts to make sure you truly get it (if you get it then it is just tedious, if you don't then you better hope you figure it out soonish else you will probably fail the exam if they weighted it as they normally do in such things).
To find pointers then you have a few methods. Without dipping into analysing the code itself (which can be very quick, but will see you wanting to know enough assembly coding for your specific device) then most will tend to use a pointer searching method.
They generally work by having you find a cheat for one particular run, noting where it is and taking a snapshot of memory (savestates typically). You then repeat this a few times to get examples from different locations. As memory locations are known for your examples then anything containing the location of the respective different locations in each run tends to be your pointer. Gets a bit harder if you have said pointers to pointers but mainly just a repeat process to find the next stage back in the nested pointers as it will commonly be called.
To get closer to answering things
Cheat codes tend not to be written out in long bulky text form saying do this at this location. Instead a shorter format is used
https://github.com/JourneyOver/CTRPF-AR-CHEAT-CODES/blob/master/ActionReplayCodeTypes.txt looks like a good example for the 3ds action replay.
For older devices I generally recommend "enhacklopedia" (it is in various places so if one link is down search for that term and it should appear).
https://doc.kodewerx.org/
Most really old cheat devices and methods (see peek and poke on the commodore 64 if you like) were little more than glorified write this data constantly to this address. I should also note that this memory editing approach is what is classically known as the action replay, gameshark, codebreaker, pelican, goldfinger (translation of the term popular in China for such things) approach depending upon where you are in the world and device you came up on. You can also edit the ROM, or at least have something that sees the console requesting a specific section and instead of giving it what it asked for the device returns your choice of data, this is the game genie approach. Editing the ROM can have far more profound effects than editing RAM where you are generally limited to infinite things and tripping flags that the game uses to do something but editing the ROM is far harder which is why there are so few game genie codes on most systems. Depending upon the device this distinction can get kind of blurry (for the DS the whole binary that the CPU runs is in memory at all points, thus a memory cheat can be as far reaching as a classical ROM editing cheat if you want it to be) , and most of those are company names that were bought and sold and slapped on anything including save editors over the years since.
Anyway "constantly write this" gets somewhat limiting. Sometimes you might want to write a piece of data when a button is pressed (never had a fight in a RPG where you are forced to lose to advance the story?), when the value falls below a certain amount, rises above a certain amount, goes within a certain range, goes outside a certain range, only write a section of memory when another section of memory happens to show a certain value and so forth. You will probably also want a mask, maybe the option to add data or otherwise do some maths...
Masks are classic boolean logic so go read up on that one. If this section is blah then do something is a classic programming loop (see IF ELSE programming loop, or loops in general
https://www.tutorialspoint.com/computer_programming/computer_programming_loops.htm ) and you tend to want to end loops rather than have them run forever when it comes to cheats.
I think I will leave it to you to decode what each line on those cheats means in general and for the cheat as a whole.
