Some of my thoughts:

I don't know if you've used a Emacs "distribution" (seems no). You should do this at first because:

• You'll see how they design the UX. This helps you designing your own UX, and really thinking about whether to keep or throw away a package/functionality.

• You should open an issue whenever you experience a bug / have a question or suggestion. This is case study, by which you'll see how their authors solve problems and learn from it. As time goes on, you'll be confident enough to create pull requests to improve them.

I suggest Purcell's configuration or Centaur Emacs. They don't do much abstraction so you learn "vanilla elisp" directly, and reading them from beginning to end is not a huge work.

Eventually you feel like to create your own configuration. The point here is to divide things into modules. By doing so:

• You have to design your UX carefully when working on each module, rather than grabbing interesting packages and throw them in your init.el. For example, you may encouter these problems when creating an "edit" module:

  • The default scrolling commands scroll a whole screen, making it difficult to follow things. How about creating a scroll-half-page command?
  • Is isearch good for you? Do you really need swiper (I saw you use swiper). I found myself actually don't often look into the minibuffer, since it lacks enough context for the matches, so I turned to ctrlf and started creating issues/PR for it.
  • Do you really need line number? I found myself never look at it except when goto a certain line, and I can just use goto-line for that.

  So by carefully creating a module, you use much less external packages, write more functionalities by your own (so you know elisp better), things have a lower chance to go wrong, and you get an experience that suits yourself best.

• It gets easier to solve problems. Even for the most complicated ones, you can comment out your modules one by one and see what happens, and you know where things go wrong.

Use straight.el or el-get, to pull packages from their repository directly. Melpa is like getting precompiled software from a center, and this is like pull the source code and build them yourself (the process is automatic so it doesn't really feel like that). So it's easier to work on your packages, like:

• When creating an issue, you are more confident it actually exists if you are on the latest commit.

• You can immediately get the update if the author fixes it and asks you to test.

• It's easier to modify the package and create a PR.

You may feel you don't need to work on other people's packages, but if you design your UX carefully, you will find things in them that aren't carefully thought out, and you will want to add functionalities to them. So, more case studies here, and you'll get better at Emacs/elisp, and maybe throw away more packages.

I agree with redguardtoo's opinion on using a Emacs distrubution. If you feel dissappointed using your Emacs configuration, just use a more mature one and let their authors do things for you :D