We learnt from the software's documentation. Books, or Help documentation. I remember knowing by-heart the entire contents of the GWBASIC manual, and thus, every BASIC statement's syntax (I used to code in Basic those days). I also remember poring through the BIOS listing of the IBM PC to help me write my first Terminate-and-Stay-Resident (TSR) program on DOS.
Later, when using Microsoft Foundation Classes (MFC), we had its documentation installed in Visual C++, so the entire API was available, searchable, on the desktop. As a matter of fact, even in the internet era, I have done this: downloaded the entire PostgreSQL manual as multiple HTMLs, and serve it off my apache on localhost.
It worked. The only downside was that you couldn't get ready-made recipes of "how to do XXX". You had to know your subject thoroughly, and you made your own recipes.
Personally, I spent a lot of money on books. I had lots of them. Dennis Ritchie's C book. Charles Petzold's Windows books, several QuickBasic books (yep, that's a long time ago), books on Assembler, books on Java, books on Pascal, "Learn X Programming in 21 Days"... shoot, I joined Columbia House Book Club just to get these books at a cheaper price! Never read them from cover to cover. Did exactly what I do now with Google. Looked for the info I wanted, read about it, implemented it. Lots of trial and error and taking those examples and modifying them to do what I wanted. Now that the internet is a plethora of information, all my books got donated to my local used book store. My book shelves are nearly empty.
This could also be phrased as "how did people learn anything before the internet?" The answers are documentation and people. The internet is just a communication medium. It's still entirely possible to learn without the internet.
If you were lucky enough there was already someone within your organisation who could program in your chosen language and who was willing to impart this knowledge. This kind of mentoring, combined with books and hacking existing code was how I first learned.
Books, and documentation & examples on floppy discs and CD-ROMs. In the early-to-mid 90s, many programming books came with a floppy disc with example code so you could at least play around with working examples.
Fixing bugs and figuring out how to get code working was quite painstaking work, especially if you didn't know any other programmers. You could simulate this today if you like -- take a fresh laptop that's never seen the internet, go off to somewhere remote with no possibility of internet (yet somehow have power to charge your battery), and try to build a website with only a "Javascript for Dummies!" book, and that'd be a fair approximation.
Books! And ones that were obsolete almost as soon as they were put into print.
Technically I didn't learn before the internet era, but I started learning a long time ago when there weren't as many resources as there are today.
Funny observation: the times when I learn the most about JavaScript are the times when I am stuck on a problem and have zero internet or way to look it up, like on vacation, or on a flight, etc. Those are the most memorable times, so what you try that works or fails sticks with you :D
With great difficulty - you had to figure out a lot of stuff yourself, actually read the docs and if a book was available, no matter how bad it was, you had to get it. You also had to write a lot of stuff yourself, very few frameworks existed.
For example, I spent a lot of time in one project (back in school still) trying to figure out how to sort things, I was so chuffed when I finally wrote a generic sorting algorithm in Delphi. Several years later when I finally got dial-up internet, I discovered that I implemented bubble sort and insertion sort.
I wanted to make the NumLock + CapsLock + ScrollLock lights go on and off (like the Knight Rider car) while processing something - I could only find some assembly code on how to access those lights and some C++ code on how to get access to those APIs in Windows 95. Used it to figure out how to write a DLL that I could import in Delphi, used the Delphi docs to figure out how to interface DLL files and my Encryption application would cycle through the keyboard lights while encrypting - took around a month of tinkering to get it working since I had no idea what I was doing - whereas now, I would post a question on StackOverflow, get a response and build something like that in a day or two.
Struggling is the best teacher.
Nathaniel Ng
I learned partly from reading the manual, but I found that most of the time, the manual wasn't enough! When Visual Basic / Visual C++ came out, the built-in help was a useful time saver, that wasn't completely sufficient either. Turns out that I had to spend a considerable amount of money on books. Two books that cost a lot of money, but also helped me learn a lot during those early days: Mastering Visual C++ (Michael J. Young) and Tricks of the Windows Game Programming Gurus (Andre Lamothe). I liked these books so much, I've still kept a copy (unlike my Quickbasic / Visual Basic books which are probably all thrown away). The most useful books usually came with some form of example code. Better still, some came with the code on a disk (or on a CD). Lastly, I also took courses, from a computer club at school, and from courses during university days.