Lots of great advice here already, and I'm probably too late for anyone to read this anyway, but I have a few things I'd like to mention.
First, I firmly believe that kabdib comment - that you shouldn't customize Emacs, or fiddle with it too much - is not good advice for the year 2020. Forty years ago (i.e., when kabdib started using it), I would have agreed with it (I'd have to be born first, though). In essence, the vanilla Emacs is a powerful text editor with macros, syntax highlighting for many languages, debugger and linter integration, split panes, great diff viewer, and so on. In short: vanilla Emacs is still loaded with features, especially if you compare it to EDIT under MS-DOS or MS Write from Win 3.1.
The problem here is twofold: due to strict GPL licensing requirements, the inclusion of new features in the Emacs core is not that fast, and (more importantly) the rest of the world hasn't been frozen for the last 30 years. What I mean is that today, the comparison is not Emacs vs. Notepad, but rather Emacs vs. (Sublime | VS Code | Atom | ...). The vanilla Emacs has literally no features you could see as an advantage over the other editors (and that's even before we start talking about modern IDEs).
Basically, the only thing Emacs has in its favor is this: it's a full-blown, incredibly efficient IDE for programming in Elisp, and it's been like this for the last 40 years. Thousands of programmers used that environment to build the tools for just about anything under the heavens, and most of their code is out there, on Emacs Wiki, in ELPA / MELPA repos, and all over GitHub.
To me, using Emacs without taking advantage of its ecosystem is simply a waste of time. So to summarize this point: you don't have to fiddle with your Emacs config too much, but one of the first commands you should learn is probably `M-x list-packages.`
---
Second, while I say you "don't have to," it's important to remember that you can fiddle with the config. The "incredibly efficient Elisp IDE" is always there for you, a single command away. You can use it to read the code and docs for any function or command you use (or want to). You can make a small change in command and have it immediately reloaded. You can put a breakpoint anywhere in any function and step through its execution while having call stack with all the (if not compiled away) variables and their values.
The browser-based editors could, in principle, offer a similar or better experience, but for some reason, they currently don't (yet). You don't necessarily have to use it right off the bat - or you can ignore it altogether - but when you need it, it's always there. Fixing a typo, disabling unused features, automating chains of commands, binding commands to whatever is convenient to you, and so on - Emacs allows you to do all of that more efficiently than any other editor I've seen (LightTable being dead and all).
Also, as for "endlessly tweaking" your config: in my experience, that's not what happens. It took me a year to learn Elisp, then I spent about two years trying out various packages, writing my own, adding some conveniences on top of what's provided, and so on. That was almost a decade ago, though, and since then, I touched my config with very minor edits every couple of months, and I tried out some new packages as they came, so maybe a few times a year? Something like that. This is because I made my Emacs fit my habits, and once I did, I have had no incentive to fiddle with it further. Why would I? It works exactly the way I want it to.
---
TLDR: first, learn how to install (and uninstall!) packages and how to customize them with the `customize-...` commands. Then, go through the "awesome emacs" on GitHub and play with any package that catches your attention. Ask for package recommendations on StackExchange or somewhere if you're not sure which to choose or if there's a package implementing what you want (there is). Then, if you wish, delve deeper: start debugging and editing the packages' code, learn Elisp in the process, write whatever helpers you need. And after that, yes, simply use the editor (your editor!) for the next couple of decades.
First, I firmly believe that kabdib comment - that you shouldn't customize Emacs, or fiddle with it too much - is not good advice for the year 2020. Forty years ago (i.e., when kabdib started using it), I would have agreed with it (I'd have to be born first, though). In essence, the vanilla Emacs is a powerful text editor with macros, syntax highlighting for many languages, debugger and linter integration, split panes, great diff viewer, and so on. In short: vanilla Emacs is still loaded with features, especially if you compare it to EDIT under MS-DOS or MS Write from Win 3.1.
The problem here is twofold: due to strict GPL licensing requirements, the inclusion of new features in the Emacs core is not that fast, and (more importantly) the rest of the world hasn't been frozen for the last 30 years. What I mean is that today, the comparison is not Emacs vs. Notepad, but rather Emacs vs. (Sublime | VS Code | Atom | ...). The vanilla Emacs has literally no features you could see as an advantage over the other editors (and that's even before we start talking about modern IDEs).
Basically, the only thing Emacs has in its favor is this: it's a full-blown, incredibly efficient IDE for programming in Elisp, and it's been like this for the last 40 years. Thousands of programmers used that environment to build the tools for just about anything under the heavens, and most of their code is out there, on Emacs Wiki, in ELPA / MELPA repos, and all over GitHub.
To me, using Emacs without taking advantage of its ecosystem is simply a waste of time. So to summarize this point: you don't have to fiddle with your Emacs config too much, but one of the first commands you should learn is probably `M-x list-packages.`
---
Second, while I say you "don't have to," it's important to remember that you can fiddle with the config. The "incredibly efficient Elisp IDE" is always there for you, a single command away. You can use it to read the code and docs for any function or command you use (or want to). You can make a small change in command and have it immediately reloaded. You can put a breakpoint anywhere in any function and step through its execution while having call stack with all the (if not compiled away) variables and their values.
The browser-based editors could, in principle, offer a similar or better experience, but for some reason, they currently don't (yet). You don't necessarily have to use it right off the bat - or you can ignore it altogether - but when you need it, it's always there. Fixing a typo, disabling unused features, automating chains of commands, binding commands to whatever is convenient to you, and so on - Emacs allows you to do all of that more efficiently than any other editor I've seen (LightTable being dead and all).
Also, as for "endlessly tweaking" your config: in my experience, that's not what happens. It took me a year to learn Elisp, then I spent about two years trying out various packages, writing my own, adding some conveniences on top of what's provided, and so on. That was almost a decade ago, though, and since then, I touched my config with very minor edits every couple of months, and I tried out some new packages as they came, so maybe a few times a year? Something like that. This is because I made my Emacs fit my habits, and once I did, I have had no incentive to fiddle with it further. Why would I? It works exactly the way I want it to.
---
TLDR: first, learn how to install (and uninstall!) packages and how to customize them with the `customize-...` commands. Then, go through the "awesome emacs" on GitHub and play with any package that catches your attention. Ask for package recommendations on StackExchange or somewhere if you're not sure which to choose or if there's a package implementing what you want (there is). Then, if you wish, delve deeper: start debugging and editing the packages' code, learn Elisp in the process, write whatever helpers you need. And after that, yes, simply use the editor (your editor!) for the next couple of decades.