I started with Hypercard and followed up with Borland C++ Builder. In both cases, there was a reference manual and many examples. SDKs (such as the DirectX one)

I started with Hypercard and followed up with Borland C++ Builder. In both cases, there was a reference manual and many examples. SDKs (such as the DirectX one) also came with tutorials and sample code. I also bought a book about C++, but it was a very bad one in retrospect, as well as the OpenGL red book. Not having access to the internet (let alone Stack Overflow) really forced you into a mindset where you were on your own, so you had to take a scientific approach to finding bugs: trying hypotheses, comparing code that worked and code that didn't, reverting changes to a known working state, and so on. I wish it had made me better at writing easily debuggable code, but I was still too young back then, so it mostly made me very good at debugging ugly code (this, and my four-year stint as a programming TA means that my most effective debugging method is staring very hard at code for a minute). After a while, I managed to get a connection to the internet. I suddenly gained access to a lot more tutorials and online resources. I spent a little while on IRC and on the Gamedev.net forums, but by then it was a lot faster for me to solve my own problems than to post them somewhere and wait for an answer. What I needed then was to unlearn all the bad habits that came from coding on my own, and it took a while (and a few team projects). I was this kind of weird creature who knew the C++ standard by heart and could find subtle errors just by reading C++ code, but who was completely unable to work in a team where everyone wasn't a C++ language lawyer. I got better.