You'll never know it all. There's pretty much always more depth and breadth around every individual "thing" you can know. Learn as you go. Apply the "best practices" you think are relevant now. Make mistakes. Just try to avoid making really costly mistakes. Find mentors if your project could lead to costly mistakes.
And now the long answer ...
1. "Working software is the primary measure of progress." (Agile Manifesto)
If you can see the edges of your knowledge, that's awesome! Pursue the edges! Keep learning! But bear in mind, you could learn and analyze forever.
2. Learn and make mistakes; but don't make "bad" ones.*
Keep pushing the boundaries of your knowledge/skill. You will make mistakes. You can learn from them. But, you don't need to be reckless.
The time you spend finding and working with more experienced developers and mentors should increase in proportion to the business value and risk profile of the project.
If you're making a little CLI for yourself: Get it working however you want.
If you're writing a bank's web portal: Surround yourself with very experienced developers.
3. "Best practices" should be written in quotes and spoken with a wink.
"Practices" are promoted to "best practices" when they're observed to be successful at accomplishing X in at least some cases. Someone recognizes the benefit of Practice A for achieving Benefit X and declares it the practice to be a "best practice" on the internet. Others agree — often for good reason. But, from that point on, we generally lose sight of why some practices are "best practices" and others are either "antipatterns" or "stinky."
The trouble is, a "best practice" is never self-serving. "Antipatterns" aren't actually diabolical in and of themselves. And, even a "stench" only sometimes comes from rot. Sometimes, that stink is just a fancy, delicious cheese...
You don't practice things like "dependency injection" (DI) because "dependency injection" is inherently valuable to the business. It's not even remotely essential to building a working product. It accomplishes something that you maybe want in your final product. But, it might also just make your work take longer for no benefit ...
So, should you follow "best practices?" Even if you don't understand them? ... Err ... yes. I mean no. But yes. But, only the ones that really apply to you and your software and its purpose.
Invoke the POAP! (Yup. My blog.)
Principles, patterns, and practices are not final purposes.
and proper application of each is therefore inspired and constrained
by a superior, more final purpose. You need to understand why you're
doing what you're doing!
(The POAP is not exempt from the POAP.)
So, you may not fully understand every nuance of DI, for example. But, if you understand the intent, you'll know if you "should" use DI, and you'll sort of implicitly understand DI better.
And, once you've release the product, you can reflect on whether DI (or whatever) was really beneficial. If so, articulate why in writing. If not, articulate why in writing ...
Bonus reading / Somewhat relevant:
Analysis paralysis is a thing. You need to analysis and learn; but, you also need to get stuff done. Balance.
You might always feel like a cowboy coder.
* You actually will make bad mistakes if you do anything noteworthy. But, you're human, I assume. So, we forgive you ahead of time... Or, at least I do. Maybe. ... Well ... We'll see.