Code in DS games is usually the ARM9.bin you skipped past to look at files, and things in the overlay folder (overlays are a crude but not ineffective way of providing a space to cycle code in and out as you need it -- no sense having you end game credits animation sitting taking up valuable memory sort of thing). ARM7 is more of a stock thing Nintendo provides to help with running the hardware, indeed you can often swap it between different games of a similar vintage and have everything work just fine, which hackers only really look at if they are needing some space to add some stuff in of their choosing.
The debugger will likely be viewing the code where it lands in memory, but those locations are known and easily referenced back to the file to edit (assuming you want that -- if it is a simple IF ELSE/CMP BNE check that a few instructions changed might ultimately solve then you do have the option to make it a cheat, which would even work on stock games if you use a cheat cart or nitrohax or something).
Say you found the love bar for a for want of a better term NPC character. Somewhere in the calculation for whether they can be your say girlfriend will involve that value, and along the path of that (before or after I don't know) will be a check on the sex (which you don't necessarily know what it is, how it is encoded or the like*). You would presumably set a break on read in the debugger for that value, at which point it would tell you what instruction read it and the 10-20 or so preceding it. You can choose to then either read the code or step through the next instructions one at a time which is where the understanding part comes in (other things in the nice gentle intros to assembly either make it a cheat, disable that area, or add in a quick add so much to my health, not being troubled by minutia and need to understand everything happening in the equation as it were,
*from the cheat thing earlier then it is not unreasonable to expect other stats to be in the same location thus you can look in the immediate surroundings, or merged with other stats of the same type (less likely here, you tend to see that more in RPGs where you might want separate tables of ATK, DEF, CON, STR...).
I have some worked examples in
https://gbatemp.net/threads/gbatemp-rom-hacking-documentation-project-new-2016-edition-out.73394/ for various things, though I will note no$gba debug version has gone freeware since I did some of those. This is all moving very fast though when most learning to hack will play around with some text, some graphics, maybe some music (DS is far nicer for this than the NES where custom from the ground up is the standard order of the day), make some cheats, learn to hardcode said cheats, disable some element of code and then start messing with stuff like this.
Knowledge of how the series/game works from a player perspective can be valuable (most of my stuff was hypotheticals -- was never a great fan of the sims), though can also lead you down false paths (indeed someone playing with code like this usually being why myths get disproven).
