I learned (intel x86)assembly from joining a cracking group when I was adolescent, it was my first programming language. Nothing beats being taught by masters of the craft and competing and contributing as a team.
Today I teach kids ARM assembly using microcontrollers like arduino unos or nanos and controlling a motor or servo, then I add more and more complexity like explaining klipper architecture, so they learn c and python.
With kids, the social part is very important, and making real things that move and react on the real world too. I suspect is of great help for adults too.
It is probably too dull to learn assembler today, on your own (alone) on a powerful computer. With a microcontroller you have a machine that is so constrained in resources that you really need to use c or assembly.
HN has very good resources about assembly, you can search them on google "hacker news assembly" or "hacker news reverse engineer", use zotero to aggregate the links.
The one thing I'd say is a real pre-requisite is to learn C. And I mean really learn C: pointers, including arithmetic and aliasing; memory allocation; stack vs heap; statics and globals. C is the lingua franca of this environment, and learning C will give you a good window into what the compiler is doing to turn your code into what's actually running on the CPU.
It's also good to understand how computers actually work. I strongly recommend the book "Code" by Charles Petzold (Microsoft Press, be wary of counterfeits and don't buy from Amazon). It starts literally from scratch. Like, light bulbs with electricity and a switch. Then it builds on that to create a fundamental CPU, and then shows how to go from there into the real CPUs used today, including an introduction to assembly language and machine code. It's a fantastic book if you ever want to do anything low-level on a computer.
Once you've got C and a basic level of understanding of assembly/machine code, I think you're ready to do something real. Start simple. The NES runs on a 6502, which is 8-bit, has three registers and only a handful of opcodes, and is single-threaded. In the past I've used FCEUX-DSP's debugger features[1], but I think these days most people use Mesen. You can use the same basic techniques I did in these articles: scan memory for the values you want (the player's score or life count; the player character's velocity), then set watch points to find the code that modifies them, then go understand what that code is doing and change it to do what you want. Give yourself infinite lives or a crazy high jump in Super Mario Bros or something.
From there you can move on to more modern CPUs and such, but the complexity goes _way_ up once you move on from environments where most stuff was actually written in ASM or very simple C without fancy compilers. I was very relieved to see how readable Super Monkey Ball's disassembly actually was.
[1] My first real game RE project was dumping PNG pictures of the levels in M.C. Kids for NES, for comparison on TCRF:
It's very windows focused but teaches skills that are (somewhat) easily transferable.
And once your more or less proficient then just crack some software. Find something old, like protected by purchasing key or whatever, and on the simpler side, don't go straight for photoshop or whatever. Its gonna take a long time but even if you don't succeed you'll get a much better feel for it in the process. Best way to learn is by doing, thats my experience anyways.
The best thing for RE learning though is to use Visual Studio to write a few programs. From the debugger view you can use the assembly, and see what your program ends up in.
You also want to think about it as the programmer. You have a MASSIVE program. You want to see where it creates files. You know that on windows, it HAS to go through CreateFile, or at least NTcreatefile function or system call. So you can watch for these, or look where they are called in Ghidra. Now you can mark all the functions in the chain using xrefs (What references this) and then get all the functions that use createfile out of the way!
And lastly, as a programmer, you know the apis. So think of what cases someone would use printf for example. There's not many. You know by the use of printf, there's some sort of logging at that location. If they use openfile. You have a good idea that all the code surrounding that call is going to be about the file being opened.
TL;DR. Start from api calls, and work backwards. Use your knowledge as a dev for what these api calls are used for. And walk that call chain and mark. Eventually every function is mapped.
https://www.youtube.com/watch?v=RDZnlcnmPUA&list=PLhixgUqwRT...
pretty easy and fun, there is a difficulty wall after a few stages though. but once you get there, you might be able to get through it with some general deduction skills.