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.
Whenever you set out to write something, write it differently than last time you did it. It takes conscious effort and a lot of getting used to but actually stopping and thinking about alternative ways of doing something is a practice in itself. When you act on these thoughts, you're most definitely practicing, and quite probably improving.
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.
I don't know about doing this in a project you're being paid for, it certainly increases the cognitive load of reading a codebase where simple things are done differently all over the place.
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.
> it certainly increases the cognitive load of reading a codebase where simple things are done differently all over the place.
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!
Consider just-you personal retrospectives. Do them at the end of sprints or projects, and consider a weekly one. I do this both professionally and for personal stuff.
There's some really great advice here from others. I'll add what I personally needed to learn:
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.)
I imagine that there are things you know about that you don't fully understand or haven't put into practice yet. So focus on understanding them, and especially understanding them by doing them.
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).
In addition to what others said, make sure you realize when you're learning or not. If it's painful to do something, you're learning. If it's easy going, you're not learning.
If you are writing software, learn design patterns and create some example application using them to really understand where they fit. Doesn't really matter what language - object oriented one would obviously work best. There are also books on architecture and integration patterns.
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.
Take on bigger technical challenges and keep a notebook for writing down new concepts you learn along the way. Of course the notebook could also be in software. But write. It'll help you internalize stuff.
