Hmm. Don't know why I had NES on the brain there. It is all pretty similar though whether you are working on a Vic20 or a current device.
So yeah find out how the read protocol for the disc/cart/storage of the system (and style of game if there are multiple) and means by which it can be accessed. Again there is often a function within the system to avoid having to have the CPU bogged down accessing the cart which tends to be called DMA, the CPU itself might have options and there are often extras that are not technically either of those from a code perspective (if you watched the signals at hardware level that might change but if you are playing with code then eh) but will yield data from the ROM.
Sometimes the disc/cart/storage is in memory, sometimes only a sliver of it is (see mapping/mappers/memory bank controllers and more besides) and you change that sliver, and sometimes there is something you first have to ask and it will show the relevant bit (tends to be on later systems or systems with large amounts of storage, though older ones will often have something like it for save games where you first have to speak nicely to the save controller and then read in a certain way).https://en.wikibooks.org/wiki/Super_NES_Programming/SNES_memory_maphttp://problemkaputt.de/fullsnes.htm#snescartridges
"How do you change what position in the code is referenced by an existing pointer?"
Is that not the whole point of the pointer? Most would define pointers as a piece of data within a program that shows the way, points if you will, to another aspect of the code that is theoretically* relevant to the task at hand. It might be more code (think the classic "GOTO" operation), might be a piece of non executable data (text, graphics, music...), might be another pointer (if you learn one of the C family languages you will likely get an exam question which is basically a nest of pointers to pointers to pointers with a few other bits thrown in and you get to decode it to show you really get pointers within the language). The pointers themselves might not be direct memory locations or ROM addresses, and later systems and file formats often do maths on the pointers to get where you need to be, but that is the part of the fun of playing hacker.
*being a filthy hacker you might wish to break a pointer, and you also have things like ROP (return oriented programming) that abuse the concept of pointers to achieve interesting results in locked down systems (not much use on the SNES unless you just want to show off or have some fun).
You asked about programs for it. There might be some and while many games will have pointer after pointer and work either at system memory or file level there will be others that stick something in the middle of each pointer, some that do a bit of maths to it, some that will use the higher bits that are never otherwise used to indicate something (indicating compression is popular here, what directory another though probably not for the SNES).
So yeah someone makes a program to allow people to simply generate the classic list of ?? bit values that are pointers, and maybe add 10h (or whatever you like) to each after a point to account for a shift of so much to fit something longer in earlier on, though nobody changes just one line so you now need a list of changes to calculate or things to reference from. So far so good but then you add the skip bytes for those games that wedge something between pointers, then you ask masking/Boolean options for the higher bits being used, some operations in case you have shifts, the option to regenerate based upon location (some pointers are current location plus pointer value)... and now you basically have a new programming language or something not far off it. As a "general case" is not really a thing then you can't even kick most of that to optional functionality that few ever use (or possibly one of those everybody only uses 10%, but each a different 10%).
To that end my usual approach runs hex editor if it is just one thing I need to change (usually making a size value larger for a file I know the format for or telling one file to look in another location, the classic repoint to use this instead hack, or I can set it up such that I do the change, press down, do the next simple change and so on for probably only still a handful of pointers), spreadsheet (modern spreadsheet programs should support hex out of the box, older ones might need a plugin), briefly consider a ROM hacking pointer management program (again they are often scripting languages unto themselves, and usually geared for systems other than those I play with, which does mean the SNES is an option here. https://www.romhacking.net/utilities/224/
being the classic example, and usually flanked with Cartographer) before saying meh and writing my own program instead.
As far as programming goes then any language you know and care to use will likely do fine here -- even a slow as sin Java program (Java is surprisingly unpopular in ROM hacking circles which I am delighted by but you do you) will likely still only take a few seconds to repoint an entire ROM, never mind just a handful of lines at a time, and it is not like you tend to have to repoint things in a ROM a thousand times a second.
That said spreadsheets are usually enough for a lot of what I do, particularly if I couple it with a program like filecutter ( https://web.archive.org/web/20170218180937/http://min.midco.net/cracker/filecutter.zip
) as combined that gives me a nice extraction tool, and most formats I want to play with have a nice end of file/segment marker I can search for to generate where the pointer should be (if end of file is here then end of file +1 is where the next starts sort of thing).