There are three areas to really study here:
1. Programming
2. Computer Science
3. Software engineering
Programming is, well, the act of writing code both in general and in a particular language. For this, find one or two books or courses on the languages you're using. Work through them, type up most, if not all, their sample programs yourself. Don't just copy/paste, don't download a copy of their source code. Typing it in helps a lot to internalize the information. Then create variations. I'm learning Rust, as an example, and have been writing up the programs in The Rust Programming Language, then I change their structure, make them generic, or modify other elements to see if I actually understand what's happening.
Computer science is more fundamental. For that, many of the algorithms & data structures books mentioned are great to study. It's good practice to implement both (algorithms & data structures) in whatever languages you're using, even if they already have them built in. Then switch out your implementation for the language standard version (if present) so you learn both the fundamentals (how they're built and used) and the standard (how they're used in your language). Pay attention to things like algorithm analysis, it gets cast aside here sometimes but it really is helpful especially in something like rendering. If you understand the relative costs of different choices you will get much more efficient programs, but also study how your actual system behaves. Sometimes an on-paper faster algorithm is slower in practice due to how the CPU and RAM actually work (like scanning a vector for something may be faster in practice than a faster-on-paper hash table or map data structure). You can go deeper and study theory of computation and other areas, but that's not going to be necessary yet.
Software engineering is, reductionist definition, about three things: working with others, working with your future self, organizing programs and systems. Two books I like on the non-technical side: The Mythical Man-Month by Fred Brooks and The Psychology of Computer Programming by Gerald Weinberg. Some parts of both are dated, but they're still relevant to today and thinking about how teams work and systems develop over time. On the more technical side: Learn how to test in your languages, and read Refactoring by Martin Fowler. Learn to use version control, even for toy projects. Create git repos and get in the habit of committing early and often (like with working with any file on the computer you should save early and often so you don't get burned by a crashed editor, committing early and often saves you from when you make a major change and realize you want to undo it).
---------------------
You can study programming without studying CS proper, but at some point you are likely to start running into decision points that will be hard for you without knowing the tradeoffs that CS (even just the introductory portions) teaches. Same thing with software engineering, it's not technically necessary for programming, but once you start working at scale (large projects or more than just a handful of people) it pays to understand that area.