> It's too hard on my own.
It can be, but it really does depend on the scale of what you're making: there's a large class of games that aren't too difficult for individuals, and a large class that are; and, in the class of approachable games, there are still fun, interesting, novel projects that can be undertaken.
> It involves a lot of planning.
This is one thing you'll learn to find a balance with by writing games. There is too much and too little planning. Don't worry too much about making them the 'right' way to begin with. In my own case I intentionally didn't look up any info. on the correct way of making games until I'd tried my own way first (which is much more fun and worked out fine). After doing that, looking up established practices was way more interesting (and my own approaches were laughably bad in comparison—but ya learn!).
> It's a big time investment.
Some are, some aren't. As others have mentioned, you can make a quick game in two days or so. More importantly though, I'd say to try it out and see if you enjoy the process: if you don't, then the time investment probably will be too much, and you could end up spoiling your love for games in general. If you do enjoy it then, whatever the final outcome of the game, it was time well spent.
> I won't really be able to make something worthwhile.
You may get ambitious about it one day after you've developed your skills to a certain extent, and find yourself with a greater interest in sharing an experience through your game than in working on it. If you get to that point, you're now in the realm of working on art, and that's got its own whole host of difficulties.
You should scale your expectations down, come up with the most simple, minimum viable product. If you still don't feel the scale is small enough, try to break off a chunk of that MVP you think you /can/ complete.
Then try.
You're probably going to make an initial version as you're learning, and your design is either going to radically change as you learn more about the problem you're actually trying to solve and the tools you're solving it with, or you'll end up throwing it away and refactoring the entire thing when you do have an understanding.
Then, when you've got something that works, you'll start tweaking it. Making X better, or adding Y; or even removing Z because you realize it isn't something that should be there.
That's the programming equivalent of the 50 pots thing. Each iteration you run being like a small test-firing, and each deployment being like a pot you actually feel like putting through use tests.