A simple (but not easy) way to improve your code quality is to only call it done when you fully understand the code you have written; only merge it or open a pull request after you understand it.
Simple because it does not require specific knowledge of broad programming principles and patterns or other technical jargon, but not easy because it requires effort on your part to learn or make additional changes to the code.
Did you copy some code that works, but you don’t know why? Are you changing an existing codebase? Take the time understand why it works. Maybe some parts can be changed or removed for your use case for more clarity or cleaner code.
Focusing on the parts of the code you do not understand creates a roadmap for your learning that can be applied immediately vs studying/learning broadly which provides value more over the long haul.
Time-box your effort to understand the code, if it is going to take too much time, encapsulate the hard to understand parts into private functions/classes as much as possible. The complicated bits can be hidden from consumers of the code.
I like to do a self-review of my code with a @github diff and make minor improvements before opening a pull request for review. This helps by zooming out to see the change as a whole and see what parts can be improved for understanding.