I don't mean to more of a sourpuss than normal, but you don't need a mentor to learn to program, you need to learn how to learn; and learn how to work effectively. Eventually the mentor will leave or the engaging web tutorial will end. What then? You get to the part that is actually hard: slogging through years of unfun debugging and polish to make (statistically) a really bad, ugly game work.

All the programming-fu in the world will not help you if you cannot develop the work ethic (or at least stubbornness) to put it to use.

Hopefully this advice will help, even if I have no idea how to achieve it. For me, it took a whole lot of trial, error and introspection while failing my way out of college.

As a beginning programmer, I've been dabbling in Java for little less than a year. But it wasn't until this summer that I truly got the hang of actual coding, when I started watching a youtuber called TheCherno and looking at actual game programming specifically, code for code.

I think that's the main challenge. Games are complex abstractions and you can't really learn how to make them if you only read the theory of programming. While it's critical to learn about algorithms, data structures, inheritance, polymorphism, recursion, stack & heap and whatever, none of these things will teach you how to literally write the code. For that, you need to learn and practice the specific methods/functions (and their syntax) for the problem you're trying to solve. Gradually, you understand how to construct them yourself (that's when algorithms come in), and that's when you go "Eureka" and can start designing stuff independently.

I wish fewer books were about high-floating computer theory and more about actual, specific algorithms (unless, of course, they are and I've just made poor purchasing decisions, as a self-taught). In fact, I often get a feeling that these authors often avoid teaching you specific algorithms. Whether it's because they're afraid that we're just gonna copy-paste it, or whether they don't want to share IP, or whatever the reason might be, I've read a couple of top programming books and none of them teach you how to specifically code a game step-by-step. Not even in psuedo-code. Let's just say that I'm eager to see what my next couple of books are gonna contain, because their topics are of or include algorithms specifically (Data Structures and Algorithms, by Alfred V. Aho etc and also the Art of Computer Programming series, by Donald E. Knuth).

I also read about people who's read tons about programming and STILL they suffer from writers block. And it's not an author's block, but rather a syntaxical one. Now, imagine an english author suddenly forgetting the english language. Personally, I've only ever gotten writer's block when I don't properly understand the body of those specific functions. But even if you don't have an entire game document stored in your head like I do, you still shouldn't get more than the conventional writer's block. The syntax block shouldn't even exist for a seasoned programmer. So learning the coding algorithms is the one thing to do to start programming, and then you should learn the theory later to enhance your programming to be more coherent and economic.

Only then should you start to create multiple functions, classes or object instances, instead of one crazy 1000-line function.

Only then should you dabble in more abstract concepts and start worrying about composition.

Nobody expects your first project to be the most efficient one, anyways. In other words, allow yourself the luxury of being a horrible programmer, at start. Don't try to be better than you actually are, just write code.

As a side note, it should be pointed out that making games isn't actually as much about "making games" as it's about "solving specific functional problems", like how to render a given shape, how to enable a given keyboard command, how to animate, how to assign variables and how "heavy" (byte vs. long) and "visible" (private/local versus public/global) those should be, and so on. "Making the game" is just the abstraction in the back of your head. The actual coding is vastly more concrete and specific than that.

Programming is kinda like Chess. The Pros aren't great because they can predict the next 20+ steps. That's just a myth, and in fact most of them can't. Rather, the Pros are great because they have learned so many move patterns that they know which pattern corresponds to which reaction. Same with programming: You get better and faster the more functions you know by heart, and when or if they should be applied. Plus, knowing the Touch method doesn't harm you either.

After all, programming is, at base, about problemsolving.