You need not have a code dump, indeed it might not even help that much before late stage things and even that is debatable.
Most of that would be cheats and searching for those. I don't know what we are suggesting for a cheat search on Switch these days (my usual example is
https://web.archive.org/web/20080309104350/http://etk.scener.org/?op=tutorial and
https://doc.kodewerx.org/ as the general principles are the same whether you are on a commodore 64 or modern 64 bit PC game but the Switch has the ASLR/pointers thing as a fairly standard affair so you will want to learn about those too to really start making things on the Switch) but it should be reasonably available on whatever custom firmware you are using or
https://gbatemp.net/forums/cheat-codes-add-and-request.412/
Love/adoration is gained by giving gifts. Find a FAQ and figure out what ones do what for a given character, give yourself infinite of said item (infinite items is usually a basic cheat to make) or infinite money to buy them (presumably pick a partner you can readily buy a suitable item for) and gift it to them however often you are allowed (some in the past limited it a bit so you might have to go sleep in between). If there is an item duplication glitch then that would also be an option.
Doing that will build up the love bar as it were, which is functionally no different to an experience bar, health bar or something like that and thus can also be searched for with a cheat (might be better to take said faq and find an item they are middling with to decrease the rate it fills up to give more chances for the search).
From there this is when assembly hacking comes in. Assembly is largely considered the final boss of ROM hacking and cheat making but here you are only dipping a toe into it.
I don't know if I want to do the full intro to assembly hacking here that I sometimes do. I will go for the slightly condensed version
Debugging as it would generally be known (emulators with a debugger are what ROM hackers often seek, in the case of the Switch and a lot of modern hardware that can have stuff run in the background and funnel out data over network, USB or something then you can even have in hardware options which have the perk of being more accurate than emulators) is what people typically use to ponder code and eventually alter it. You can do a static analysis (what your code dump thing arguably is) but nobody really does that in anger for game modifications like this.
One of the nicer features available (though not in all debuggers) is something called breakpoints (see the pause/break button on the typical full PC keyboard, it is related from when it was more of a thing on PC). These allow the code to stop when certain conditions are met, log/watch points opting instead to write it down to a log file (useful if there are thousands of reads but it is only certain scenarios you care about).
In the baseline for a good debugger case these breakpoints line up to the three main things memory has done to it.
Break On Read will stop when a given area is read. BPR being the shorthand form that most things will use.
Break On Write will stop when a given area is written to. BPW being the shorthand form.
Break On Execute will stop when a given area has code executed in it. BPE or BOE depending upon the debugger/emulator.
More primitive debuggers might have a Run to Line option which is a simpler case of break on execute. More advanced ones might have break on access which does multiple of the above (execute will necessarily read a piece of memory but it is treated as a different concept).
What one you pick will be left to the hacker but it is usually fairly obvious and you generally want to get as close to the thing you care about -- doing a break on write to your gold will get you most places you care about eventually but the sensible approach might be to do the read instead and thus get the game when it checks how much gold you have , and if not gold then infinite life also is good here as it will prevent full health bar issues (if the game wipes you out and checks to see if you are 0 health before your write comes in and sets it back to full, I used to tell people go to goldeneye on the N64, use gameshark infinite health and eat a rocket from an enemy but I think I need to find a more modern example) and might even speak to knock back -- all well and good fighting the final boss as a level 1 character but if your stats mean 9999 damage would be done with corresponding knock back then you might have trouble.
The Switch uses a modern(ish) ARM processor at its heart which is nice as unlike some older stuff you might stand a chance of finding something modern on it. I would probably still look at the first few chapters of art of assembly
https://www.plantation-productions.com/Webster/ and
https://stuff.pypt.lt/ggt80x86a/asm1.htm though before moving sideways.
I usually break down instructions into three main camps.
1) Housekeeping. CPUs might be very fast but they have limited memory (when a system is called 32 bit or something it is because the registers, of which about 20 is what most have with the NES dropping to 3 8 bit ones depending upon your perspective, inside the CPU are that size, give or take a few marketing slimes trying to pump them by picking something irrelevant elsewhere) and thus need to shuffle things in, out and around.
Whatever the equivalent of mov (copies data from one register to another), push and pop (puts data in registers to the "stack" to restore them later with pop when you need it back) and memory loading (assuming it is not part of mov, which for most CPU families it is not)
2) Maths. Anything you find on some kind of spreadsheet
https://help.libreoffice.org/Calc/Mathematical_Functions or a basic intro do digital electronics course (Boolean logic gates, shifts, rotates...) is what you might well have access to. Instructions vary on a per data type basis as well for this so this is what usually pumps up the instruction count to hundreds if you look at one of the big scary complete lists of instructions for a modern processor.
3) Program flow.
Maths and fiddling with internals is nice but the real fun comes from changing the course of code depending upon things (a game often being literally defined as a series of decisions you make). If you have ever done any kind of programming or intro to it then the loops aspect is what this is doing/dealing with, albeit probably under a different naming approach
https://www.tutorialspoint.com/lua/lua_loops.htm https://www.tutorialspoint.com/cprogramming/c_loops.htm
IF ELSE tending to look more like CMP (compare) and BNE (branch if not equal) or one of the many options.
WHILE tending to have something that sets a value when it is done/adds to a counter and when that is done a CMP or possibly an interrupt (checking every time is time consuming, instead interrupts are given by hardware to force it to do something when conditions are met). FOR EACH also looking like those. For this game the ideal case will probably see you fiddling with something here but more on that shortly.
There were also a couple of alternatives that might achieve an acceptable result. When you start a game you probably get to pick name, sprite type, stats of some form and whatever else, with sex being a part of that process. Accordingly somewhere in there will be a value to reflect this. I imagine it is going to be a simple binary thing (effectively this would be a flag, much like poisoned or not in a normal RPG) with 0 or 1 depending (don't know which way it will fall) and you can probably find this by doing a cheat search either in the menu where you select it (can work, sometimes only sets set after you press go) or by making a savestate before you select and restoring that a bunch of times/running through new character a few dozen times.
Once you have that you can use that instead of the love/adoration bar -- chances are the game does some kind of IF [love bar] = FULL AND [sex XOR NPC sex] AND [NPC = marriage candidate (don't know if there are too old, already married or too young NPCs in the game but there is probably a value)] AND [player not married] THEN [unlock marriage proposal] type deal in the code. Part of that would necessarily involve reading your character's sex value and thus you can change it to be something that flips it around or allows you to do the bisexual thing -- XOR above will only return true if the two inputs (presuming 1 or 0) are opposite, does not have to be XOR and you could make it any variation you like depending upon your chosen path (only gays, only lesbians, bisexuals be a thing...).
You could also work backwards from a married state (any part of the equation or its results can be looked into in scenarios like this) but that is more hassle than it is probably worth unless there is a divorce mechanic you want to look into.
Alternative the third was if you find said sex value with cheat approaches as detailed above then you can presumably flip it to the opposite one with a simple cheat or save hack and anything it does based upon that value will be tweaked accordingly. Whether this changes sprites, menu contents or not I don't know. If it is just sprites/models that get changed you can probably find the sprite/model in the game and swap them around as well, possibly also remove the baby option if that is one like in older games -- it is not like play as NPC cheats as chances are the male and female options have the same animations and such.
You might go the other way and find if the NPCs have a sex value and flip those around as well as that presumably does not change much.
