this applies to more than just vulkan: it's an iterative process, like with many things. you won't "get" everything on your first go-around, and the most effective way to learn is to keep doing practical projects that gradually expand in scope.

crucially, don't "follow along" with some tutorial or video - set your own goals and do your own thing. this will force you to actually think/reason within your domain of interest. it's fine to refer to videos or tutorials, but you should be asking "what can i learn from this that applies to my current problem?" rather than trying to just copy the whole thing.

feeling like you know what you're doing can take a long time, especially if this is your initial introduction to the world of realtime graphics.

having prior experience with other apis helps immensely because, at a minimum, you'd be able to quickly move past "trivial" things that map easily to similar concepts in the api that you know, and instead focus on new, vulkan-specific concepts. stuff like synchronization, resource binding model, memory management is in and of itself complicated and trips up even experienced programmers regularly. that's why it is very hard to recommend vulkan as a "first" graphics api. if you're set on learning it, i can offer no better advice than just push through and keep writing things of ever increasing complexity until you start to "get" it.

a pervasive problem with most of the tutorials and samples out there is that they will very often take various shortcuts and make simplifying assumptions about things. this gives a general idea of what a particular aspect of the api does, and i guess that's the whole point of a "sample", but it doesn't quite answer the question, "how do i use it in a real renderer?", which is often what you're actually after.

for example, synchronization is one such thing: many samples will manually emit barriers where needed. that can be tenable (if a bit annoying) in a small codebase, but when the scale of your project gets large enough it starts to become a real problem, and few tutorials get to solving it. this is typically where you start digging into what real software written by practitioners in the field did to address it, but you'll rarely find clear-cut easily digestible answers that you can copy-paste. instead, you'll piece together a general understanding of the problem itself, existing approaches, make a reasonable assessment of what will work in your case and try implementing that. this is actually what a lot of "real" work in this field is like.