When I first learned to program, I made some nice little fun apps, compiled them to executables, ran them, and sat back. But something wasn't right. I knew that

When I first learned to program, I made some nice little fun apps, compiled them to executables, ran them, and sat back. But something wasn't right. I knew that the code I wrote was doing something, and I knew that it was doing what I told it, but I didn't know why. What is in this binary executable that makes the computer print "hello world"? I started digging. I found assembly. I found disassembly. I got into cracking and exploits. SoftICE. Unlimited ammo in games. Patching. Sniffing serialzz in shareware. Etc etc. My point is, if I had just been happy with printf("Hello, world!\n") and moved on, I wouldn't have the incredible understanding I do now for what goes on under the hood. I wouldn't know what an executable is, or how to bend it to my will. This knowledge has always been powerful for me. Game programming is like this too. You can install Unity and make a basic game, hell maybe even make a few bucks off it. But what the hell is happening under the hood? What if you need to do something Unity isn't capable of? Where does that leave you? Maybe some people want to just make a game and be done with it. But I like to know why what I built is actually working. It's worth the time it takes. OpenGL extensions, FBOs, triangulation, etc are all complicated and hard to understand, but once you know how it all works you know what's possible and what isn't, and you don't need a (proprietary!!) framework making that decision for you.