If you decide to build your own engine from scratch using only barebone frameworks, like OpenGL, then yes, it IS hard. But in the advent of easy to use tools like Game Maker, Unity, Stencyl, Game Develop, etc. the only thing you REALLY wants to take care of is to make actual game content - models (or sprites if it's 2d game), music/sounds and levels.
Granted, this is like 90% of making actual game and maybe, just maybe I shouldn't be speaking about it since I didn't released proper game yet (The Art of Tiles and Adventure Cavern don't count as those aren't finished), but from what I've learned from my tries at this I can assure you that most of glitches comes from trying to reinvent the wheel rather than making actual content (where reinventing the wheel equals to trying to write your own collision detection algorithm, etc.).
Of course, you can't run away from coding, but when you have some foundation to build on - be it game engine like Unity or CraftStudio (last has that cool N64 bit to it - you should definitely check it out!) or framework that does most of heavy lifting for you (for 2D games, Allegro is my favorite, as well as Johan Peitz's, the very same person who made such hits like Happyland Adventures, Alex the Allegator 4 and Icy Tower so that's saying something), it isn't nearly as hard.
Also choice of programming language for your game matters too. Some languages like C#, Java and Pascal are very easy to pick up and modern compilers for those makes very efficient code which is well-suited for games (Minecraft is running on Java, Blockscape and Terraria on C# and Hedgewars, open source clone of Worms runs on Pascal - the only C/C++ parts are GUI code and Lua interpreter and it's only because Lazarus and pascal bindings for QT and Lua were in too early phase to be usable when project was started, whole engine stuff is written in Pascal).
Other languages, like C/C++ are in most cases an overkill for games unless you do some heavy rendering or do some expensive calculations.
Why? Because of thing I like to call Pointer Hell.
In most C/C++ APIs pointers are used like... everywhere, even in places where passing them to function/procedure by value instead of by reference (which is what pointers roughly do, to those of you who aren't coders) would be enough, one of best examples would be WinAPI MessageBox function:
int WINAPI MessageBox( _In_opt_ HWND hWnd, _In_opt_ LPCTSTR lpText, _In_opt_ LPCTSTR lpCaption, _In_ UINT uType );
For those non-programmers around us, it LPCSTR, HWND and UINT are types. LPCSTR is, of course pointer to a string.
The hell? All this function does is to show message window, be it OK window, OK/Cancel or Abort/Retry/Ignore. Yet, it requires pointers to text to be displayed (which won't change there).
Then you deal with such "nice" things like memory leaks because you forgot to dereference some pointer somewhere, which are almost untraceable in larger projects.
That's what I'm calling Pointer Hell.
Of course pointers are nothing to be feared of and they have some serious applications like lists or tree-like structures. You should definitely make use of them, when they are needed.
Where "when they are needed" means "only if you can't do it with normal variables and passing parameters by value or such approach gives some serious lag".
Here it is place for my favorite quote about C/C++, by David Keppel:
C++ provides a remarkable facility for concealing the trivial details of a program - such as where its bugs are.That is SO true.
I hope this little post has given you something to think about. Maybe some of you will change your tools to better ones - you can dig hole with a spoon, but isn't shovel much better?