Don't take what I'm writing too seriously, these are just my opinions and a list of things that I wish I knew when I started programming and even into my intermediate years. I'm still learning all the things!!
If you're using an LLM or "vibe code", stop now. Language models don't help you become a better programmer, they erode your skills and stifel your development. AI has its place and it's not writing your code for you. Maybe someday? But not today. This is all I'm going to say about AI.
Understand that real people had to program the software on the machine you're using to view this document. Nowadays we're less exposed to lower level workings. I.e., most introductions to programming are in a browser or some interpreted language under the guise that doing lower level stuff is going to be too hard. Programs are merely 1's and 0's that are being fed too and executed by your computer's processor. There exists a set of tools that take your program (Your source code) all the way to machine instructions (1's and 0's). So If we can reduce the number of things between you and machine code on the processor then you're going to be in much better shape in terms of learning and excelling at writing code.
Here is a practical example of how you can simplify the translation process from source code to running program. For Windows I recommend Casey Muratori's intro-to-c series. You can still follow this if you're on Linux or MacOS some things will be slightly different. The video shows you how to get a C compiler set up on Windows. If you're on Linux this process is pretty straightforward web search for "gcc (your linux distro)" which should give you a command to run in the terminal to install gcc. On MacOS install brew.sh after you've done that, run "brew install clang" in the terminal. Don't worry too much about your choice of text editor or IDE. Some good options are notepad++ and sublime text. (I also recommend watching the first 10 or so episodes of his Handmade Hero series [5]) There is tons of wisdom and generally great advice for beginners, no prior knowledge is assumed.
Heavily scrutinize learning material on programming there is more bad advice out there than good. Learning to find and differentiate between good and bad resources is an important skill. Don't buy into any "you have to code like this otherwise you're doing it wrong" nonsense. For reference here's a list [1] of terms/sayings that could indicate poor learning material.
This includes things like: compilers, text editors, IDEs, operating systems, virtual terminals, and debuggers. I fell into this trap during college. I used to think that Zig [2] was the best thing ever and If you weren't using it then there was something wrong with you. It was never the Zig compiler/toolchain. The important thing was understanding how to use the Zig compiler effectively to generate reasonable machine code. It turns out most systems language compilers can also generate reasonable machine code. They often even use the same tools to do so. At the end of the day these are all just tools to produce programs that your computer can run. I'm not saying you should use bad tools though! Some important questions to ask; Do you understand how your source code is being transformed into a runnable program? How much influence do you have over the translation process?
Understand how memory works. Memory is one of the most important things to know if you want to get good. Everything your program does is a data transformation problem. You need memory to do this. Your program's job is to transform data. Anything that gets in the way of this or obfuscates it is simply work that the computer didn't need to do. I don't want to prescribe anything in terms of how you should write your code but I generally like it when I can read through a program and it reads like what it does. (This is honestly kind of a low bar!) People are really good at making messes unfortunately.
To rephrase this you are responsible for your dependencies. The moment you make the decision to use someone else's code you are now responsible for it. It might as well be your code. A big mistake I see people make is downloading a dependency and pretending like they don't have to care anymore. Another mistake people make is haphazardly pulling dependencies into a project. Choose your dependencies wisely. Generally if you can write something yourself you probably should especially in longer lived projects. No you don't need that dependency that checks if a string is a number. Be wary of people who obsess over shiny new "things". Aka "Shiny Rock Syndrome" this concept is tangential to the above paragraph on being religious about your tools.
I'm not trying to be cute with the header. Frameworks are roughly defined as larger software dependencies that enforce a specific mental model and solution to a problem. The big issue I take with frameworks is the lack of transferable knowledge after learning them. Honestly I would rather work at Taco-Bell than have a job programming for a specific framework. Trust me you don't want to be a framework Andy. Here is a non-exhaustive list of fundamentals [3] that you should be comfortable with. You can do 99.999% of stuff with just these concepts. Gaining competence at these things will make you a better programmer.
Read other people's code. If you don't know how to do something then you can generally find someone's implementation somewhere. Reading code is a good skill. You have to read a lot of your own code.
For people that program for a living. This is very important. You need to make time to improve. You generally don't get better at work. If you don't like what you're doing at work, find a better job. If you have a programming job that keeps you engaged, are satisfied with the people you work with, and are passionate about what you get to work on, treasure that job. Don't forget to take time to practice though. You can find a better job by taking time to practice, learn, and build things. If you can't find the willpower to program after work it's a sign that you need to put less effort into work. Your long term development as a programmer is 1,000,000x more important than closing some Jira [4] ticket. This will also make you more employable if you want to program for a job.
[1] - Smells like bad advice
"clean code", "object oriented", "functional", "microservice", "premature optimization is evil", "agile", "dry", "framework", "design patterns", "SOLID", "vibe coding", "encapsulation", "inheritance"
[2] - Zig programming language
[3] - Some fundamentals
"stack data structures", "pointers", "the stack", "the heap", "arrays", "memory", "linked lists", "trees"
[4] - Jira :(
[5] - Handmade Hero