In my humble opinion, it's about 10% programming, and 90% design and approach.

The simplest example I can think of is reducing a health value when a character takes damage. The code is really straight forward:

Health -= DamageAmount;

This is a game mechanic and the programming to implement it is pretty straight forward.

One thing that might help is to rethink how a game works on the backend. Rather than thinking of a disconnect between code and mechanics, think of the code as an implementation of a model. Like, a real time simulation. How that model / simulation should look and behave should be defined somewhere else, such as in a design document (ideally), or in your head. The goal of the code is to faithfully create the model, in a mathematical and logical sense. Technically, you don't even need graphics to have a robust working model (see: dedicated servers). The graphics are just a visual representation of the current state of the game model. Input is a way for people to change the state of the model. Networking is just a way to communicate the state of the model to other connected systems, and to send input requests to change the model state on the server. UI is entirely an aesthetic used to communicate to the player the state of the game model. Inventory is just a part of the model, which may or may not play a part in the game, depending on the design (does a bag weigh you down if you have too much inventory? etc).

So. With all of this in mind, I encourage you to create a text based adventure game. No graphics. Just text in a command prompt. This will force you to spend 95% of your time building out the conceptual model of how the game model works. Maybe if you just have a knight fighting a goblin, you'd be able to build enough structural scaffolding to understand how the backend model should look, behave, and interact with its components. Once you get this down and working well, you can optionally add graphics. But the mechanics and implementation will already be there. You'll eventually understand that the model you're using to represent the game state is view independent and doesn't need screen output. This is pretty much what most game programming is, and there's a lot of math to help create the model (think of calculating the trajectory of a projectile: 95% math, 5% graphics).

Lastly, this stuff mostly comes from lots of experience and practice. There might be books that might help with this, but it's kind of hard and silly to write out a concrete list of rules on how to do this because every case is different. It's more about adopting a good working practice. For me personally, I generally write out how my model should work, generate any necessary sketches of how the output should look, and come up with some idea on what kinds of numbers the model should output. Then, I come up with a code approach which creates the model and those numbers. The coding part is pretty much trying to create a logical model / simulation of the problem. Then I run the model / sim and see if the game output matches my model output. If the game model matches the design model perfectly, I am done. If the game model doesn't match the design model, it's time to ask two important questions:
1. Is the game model a correct implementation of the design model?
2. Is the design model a correct model of what I intended?
Sometimes, a game model is a correct implementation of a design model, but the design model is flawed and you have to revise the design model -- which I think is fun, because you learn! You discover you made some wrong assumptions!

Another example to drive the point home:

You could create a model / simulation of our solar system and try to get it to be as accurate as possible. You can easily lookup all of the planetary data, such as size, distance from sun, orbital inclination, orbital period, etc. All of the mathematical models are available online. Then, you can run the simulation for an accelerated time period. Where are all of the planets positioned after 365 days? Do the simulated positions match up with the positions in real life? IF the numbers match up very closely, you have a good, working model. Then, things can get interesting and you can start asking some interesting questions, like "What happens to the model if I change the universal gravitational constant?" or "What will the solar system look like in 10,000 years, or 1,000,000 years?"

So, yeah... I hope this gives you enough to chew on for a while.

Thanks a ton, slayemin! After reading what you wrote, I realized that I might have been thinking about things in the wrong way. I've got my bachelor's in CS and had a few game programming courses, and I think what I've been doing wrong is trying to jump right into things without properly planning things out, as I have done for most of my college projects. I don't know why I would think it's any different. I'll definitely work on a text based game to start out, I think that would be the best way for me to really just get a work flow on how I'd go about solving challenges that game mechanics will eventually give me. I will try your approach, of sketching things out and creating models. I'm a very visual person so that will probably help me a ton. Thanks for all the ideas and suggestions!