What are the essential fundamentals someone needs to be a good coder?

Glad you're here to ask this question, you're in the right place!

it's never really keeping with all the latest technologies it's all about understanding said fundamentals

100% agreed. And what are those fundamentals for coding? I think its just the basics needed like variables, control flow, functions, and what classes and objects are. After that there are books on OOP, functional programming, Clean Code, etc. But its easier to learn more complex stuff by doing. For getting that first job having fun with side projects is key.

is there some learning path to follow

Essentially building something is key to real learning:

1. Google around about a language of your choice to get warmed up
2. Work on a project yourself. Don't just copy code from a tutorial into an IDE, but rather pick something fun and new that you really want to do.
3. Go back to google to fill in what you don't know. Switch often between studying and doing for best results.

Examples:

Before I got my first full time tech job after school I did a bunch of little exploratory projects for a few months. I implemented my version of malloc in C and tested it's performance - that worked. Then I tried building an iOS app that used GPS, head tracking, spatial audio libraries and didn't really finish anything but played with some libraries. Then I changed some strings and margins of a React template and shipped a personal website. After that I searched for game engines in javascript where my idea was I would train an AI to play them really well, record youtube videos as if I was playing them for real and go viral. Never really finished this but played a perfect game of snake programmatically and I stopped there because I got hired.

I never felt like I'm learning

It feels like you have a negative view of your progress and/or experience with coding. First of all, you probably know a lot more than you think. But the metal side of coding was also really tricky for me - it wasn't understanding OOP that was super hard but rather what the IDE means when it says "Build Failed: 43 Errors, you seem to suck at this". These are some "fundamentals" on the mental side:

• #1 Positive self talk. When there are errors DO NOT think "Wow I'm stupid" or "S*** I messed this up" - instead know this is super normal - Staff engineers at google also write bugs and have errors all the time, catching them is good. Bold red error messages are unfortunately the IDE's best attempt at a gentle reminder saying "please adjust a few minor things because otherwise this code won't quite work yet". ($100 to whoever changes this)
• Configuration/set up getting started can be the worst part of coding. But it's not just you who spends 5 hours trying to just start a new project and it isn't working at all yet. Everyone will have 10 errors getting a project running locally on a new machine. It does get easier once you just know and expect this.
• You need to give yourself regular breaks (1 min video here). Don't wait to have dinner until after you get this feature working, or see friends once you finish part one. Take the breaks and know you're making progress at something really hard even if there are a bunch of errors right now. It'll be easier to think after a break - and your physical and mental health are always most important.

One more thought that didn't fit in the last answer is: whatever coding you're doing it's fundamental to break down your work into small bite sized pieces and take them one at a time. (1 min video with example here)

For fundamentals, I'd describe the core as understanding the common constructs of writing and organize the code. Programming itself only has a fixed number of permutations to do things and often times constructs across languages do the same time but the syntax is different (a for loop in Ruby has different syntax than a for loop in Java, but we'd still expect them to behave the same way). Understanding what these common constructs are means that your time learning something new will be more focused around the specific information you need vs. having to read some documentation end-to-end and having to parse through a bunch of fluff.

The personal example I keep giving on Taro for fundamentals is that I'm an Android engineer, and I haven't touched backend code in years. But I've been able to provide design feedback occassionally for the backend simply because I imagine the backend codebase to be architected similarly to the Android codebase. I don't know the exact tools and technology for the backend, but I can identify certain pieces of functionality and assume there's something that has to be able to behave in a very specific way to accomplish that functionality. So I'd hear the word "Kafka" a bunch in these reviews: I've never used Kafka ever, but I do know that something effectively needs to be an event bus for services.