Here's a bunch of tricks one should know if one wants to learn Elisp:
1. You can use describe-function (C-h f) or describe-variable (C-h v), as well as various apropos functions (starting with apropos, C-h a), you can find documentation about pretty much everything in Emacs, down to every single internal function or variable of any bit of Elisp code.
2. When you do that, you get a help buffer that almost always starts with something like "foo is a variable defined in `foo.el`". That "foo.el" bit is a link. You can click on it (or move your point to it and press Enter), and it'll land you straight at the definition of that function/variable. This is your shortcut to jumping straight into relevant source code of everything. Including C code, if you dig yourself into Emacs internals.
3. You can navigate to the help buffer in 2 from plenty of places, including e.g. the list of current modes, or description of a mode.
4. When you're playing around with Elisp code, xref-find-definitions (M-.) will take you straight to definition of a function under point.
Emacs is thoroughly documented and cross-referenced. Your own installation is its own single, living codebase - and you can navigate through it as such.
One important thing people should keep in mind, if they're starting only with Emacs navigation features for code and docs, is that they're missing crucial information that's in the manuals. One of the manuals is like a combination of the "API docs" you'll find in the docstrings, plus all the narrative around those, which you won't find in the docstrings. If a newbie is told only to browse docstrings and code, they're doing it on hard-mode.
And if a person makes sure they have the manuals installed (sadly, the Emacs Lisp manual(s) don't come installed by default in distros I've seen, which I think is a tragic mistake for uptake), and learns how load the manual in Emacs Info browser, and learns keys the Info keys like `i`, `s`, `[`, `]`, and `u`, I think they'll be glad they didn't try working from manuals in the Web browser.
Also, I wanted to start with making the code files more accessible and concrete, and generally tell people to try thinking differently about this. The reason is that I've suspected that a systemic barrier to accessible Emacs hacking was being created in the bureaucratic and obscuring direction things were going. (And it sounded like maybe this person was a victim of that suspected problem, since, when I started, it was much easier to get into, in the ways I described.)
(FWIW, I was able to write some Emacs extensions by starting with the approach I've suggested, including: https://www.neilvandyke.org/emacs/ )
But you can easily jump around very deep into packages and compile them with few changes to suit your need. Your last resort is advice(https://www.gnu.org/software/emacs/manual/html_node/elisp/Ad...). Most of the time you don't need to and they have roughly the same benefits of your distro maintained packages vs you vendoring and compiling your own little world.
There's one subtle but huge barrier to learning now: it used to be, you'd see Emacs add-ons posted as single text files, and it was all very accessible. And you'd copy that file into your home directory, and edit the Emacs Lisp of your `.emacs` file to connect it. You were already writing Emacs Lisp, and the files with more Emacs Lisp are right there.
Now, some well-meaning people made Emacs package managers (and there is some valid motivation for that) that take away this introduction of toes-dipped-in-the-water with quick transition to jumping in altogether, and then further hide the code from you. And if you ever do find the code, it's often directory trees with a dozen different "professional-looking" bureaucracy files in the top, and the source code buried somewhere else.
Which I assume gives people the impression that it's another "stack" to learn, where a lot of things are automated and have opaque layers of abstraction, and the bulk of the work is simply figuring out how to do something despite other people's piles and piles of bureaucracy. And then the next step is Web searches and cargo-culting from solutions of unclear validity from Stack Overflow.
Emacs is supposed to be an exceedingly accessible and incremental thing, where you're changing the code of your running editor, which you realize is a kind of super IDE, as you start to immediately learn its features for this kind of programming.
Consider ignoring your Emacs package managers, get the two main manuals up in Emacs Info mode, start using your `scratch` buffer to evaluate expressions like you find in the docs, see how to navigate between code and docs and keys, see how to turn on the debuggers, look through some code for some add-on packages, to see how they did those fairly well-scoped things. Somewhere in there, start making Emacs do some small thing that you want it to do -- and maybe make that your initial motivation and task, and everything I just mentioned was as-needed, in support of that activity.
It's a different approach from how we often have to work, in the current brogrammeresque world, and maybe a nice weekend/evening break from paid work. And -- though we might want to pretend otherwise, if we want it to be a change of pace from work -- the exercise of this different approach can mean skills and perspectives that we can bring back to the paid work.