Okay that makes sense to me. So, (Exp) I'm going to display a sprite on the screen in a certain fashion, so I would make that into a separate section (library / engine) where it could be reused over and over. (in a very generic way) if i understand what you mean correctly. I do agree that it seems like making an engine would be the best way to fully understand how it works. I suppose I'll start looking into that. Any suggestions / articles / books to read about the subject?
Yes. The main thing is to have the separate lib folder where your engine code will go, and that it has no dependencies on the game code. Once you have this, now you have an engine that you can include and use in multiple games.
But, ok, for the specific example. You should begin by defining the thing you want to do, and then for each "assumption" in the task ask yourself if you can abstract it at any higher level. So you might begin with "i want to draw an alpha-blended screen-aligned textured quad". Now of course, you can simply make a new function in your engine somewhere that takes a texture pointer, UV coordinates, some XY screen coordinates, width and height, and it draws the quad. Done!
However I'd then ask myself things like... "Do I always want to render this alpha-blended, or sometimes using other blend modes?" "Do I always just want to render a quad, or do I really want to be able to render a generic mesh?" "Do I maybe want to render a generic mesh with different materials, maybe with different scalings, etc?"
I'm not saying that you should over-complicate things for yourself, only that thinking things out ahead of time will make life easier for you later. If your game is only 2D, or you're only doing the HUD, then drawing screen-aligned quads is a perfectly ok thing to do. Also, defining your functionality at higher levels will make it easier later if you want to make your code platform-independent. Still, that's a separate issue.
As far as starting out, I'd start with subfolders for math, graphics, and audio, since those are the basic functionalities that you'll almost always need. Then as you get more experienced everything else will start to fall into place.
I dont have recommendations for books/articles, but maybe others do. I think the best way to learn this is to focus on a small-scale game and then do it. Yes, writing your own engine is more time consuming, but you'll learn more. Also, if your project is modest (like for example a 2D version of Asteroids, or something like that)... then the amount of stuff you're writing for the engine is really not that much. In fact, your entire graphics lib code might be like:
void InitGraphicsEngine();
void BeginFrame();
void RenderTexturedQuad(...);
void EndFrame();
I mean, that's an extremely simple case but in theory you could start off with very little engine code and build a whole game on that. Then as you progress you'll want more functionality... like you might want to be able to rotate those sprites... and as you do this you'll learn more about all kinds of things without it being handed to you by someone else's engine. More work, yes, but more learning too. =)