Regarding 2, how do you suggest I avoid "spinning my wheels and learning nothing"? Over the last 6 months I've becoming increasingly aware of this problem with me, but I don't know how to fix it.
This approach scales from the tiniest pieces of code to whole systems. If your last loop was a simple `for` loop, try writing the next one as a call to map function. If your last loop was implemented as map, write a simple `while` the next time. If your last app used Postgres for persistence, use Redis or CouchDB for your next one. If you're comfortable with MVC, use MVVM for your next project. If you're fine with dynamic typing, try using statically typed language or dialect.
Seriously - do it. Nobody is going to say anything to you: they all do the same to stay relevant, even if they know it's not the best strategy for a team as a whole. Make it your policy not to repeat yourself and only fall back to the tried-and-true ways of doing things if there are external circumstances which put you under some great pressure.
After a couple of years of this, you'll accumulate most of the techniques and skills you could ever need. The techniques and skills I talk about are transferrable between tech stacks to a certain degree, are impossible to learn/master quickly (no matter how intelligent you are the amount of information is simply too great) and really matter in practice. That knowledge is what differentiates senior programmers from others.
Anyway, good luck!
Four years in I'm hoping the OP has seen a pretty broad range of different styles and approaches and is now ready to hone their craft with smaller improvements, and is no longer struggling just to get something working so they now have some extra energy to put towards maintainability and overall system design.
It might be better to try to define and refine a consistent style that can be applied to an entire project, that way you have to evaluate all the options, and do everything intentionally, but also you're not sending the next dev back to the syntax manual every time they try to read a new function.
But simple things are being done differently anyway, all the time. There's too much variation in how you can code anything. The most trivial functions, like leftPad, can have dozens of implementations across a couple of projects - each as correct as the others, some abstracted, some inlined. Above a certain proficiency level, programmers are expected to intelligently recognize leftPad when they see it, even if it's called `frobnicate` and is implemented backwards (whatever that would look like). How can you expect programmers to do this without them going through a large set of sample implementations? Are they going to wake up some day to realize they got enlightened and now have no problems with dealing with leftPad in any of its many forms?
I find the argument of "increased cognitive load" entirely unconvincing. Yes, the code should be optimized for reading. But, as every writer knows, how you write depends on who are you addressing. In other words, it's both insulting and counterproductive to write your code as if your readers are bird-brains with severely damaged hippocampus. Your readers are professional programmers who know their craft - possibly better than you do - so have a little faith in them!
I got comfortable with the small subset of the language I knew, and then used those tools to try to tackle all problems. I eschewed some of the more powerful abstractions because they seemed complicated and unnecessary, and because learning them would take me longer than forging ahead with the tools I already knew.
What I didn't realise, and seems obvious in hindsight, was the time to learn those new tools was an investment. If I knew them, I would not only be able to tackle problems faster than I could with my current tools, I would also be able to tackle far larger problems than were feasible to do with such basic toolset.
I think a possible rule of thumb for when you are being limited in such a way is when you're hitting a ceiling - when there's a complexity point you can reach, but no matter what you do you can't seem to push past it to make bigger/better things, it's time to "level up".
Another possible rule of thumb is if there's some framework or library or technique that others seem to be using and you look at it and think "but that's way more complicated than how I'm doing it!". Maybe it isn't unnecessarily complicated, maybe that extra complexity is the "cover charge" for being able to create larger and more powerful software. (An example: using an MVC framework rather than a bunch of pages with in-line database queries and templating.)
And if by some miracle you don't have enough of those things, spend more time on HN ;)
Edit: Getting a mentor can be tremendously helpful. If you work at a company see if there's anyone you can get paired with. Someone more experienced is great, but even someone at your level is likely to know some tricks you haven't learned yet.
Alternatively, ask a friend, go to meetups, or you can even hire people online to teach you how to code (on freelance sites etc).
More here: https://codewithoutrules.com/2017/04/17/learning-without-a-m...
For everything in your tech stack - find out the sweet spot use cases and the ones where really you should use something else. For example with databases - don't repeat your data (aka normalization) is common - when does that not apply?
Spinning your wheels would be things like trying new languages, frameworks, etc. for the sake of just trying them out. It's like going to a car dealer and test driving without any real need or intent to purchase - literally spinning wheels :) You might be fooling your brain that it is learning when you are really just trying something new that is nearly the same as something you already know.