What was it like to self-learn programming before Stack Overflow? (2016)

I'd hoard programming books, magazines, and articles. Now, I just rely on the internets, keeping a file of useful links.

I'm of similar vintage, although my father was a mainframe technician, so I had some significant on-site expertise to draw on, even over the 6502 and Z-80 boards in our basement. One thing I've noted, now that I teach programming to the Stack Overflow generation is that we had to be much, much better at troubleshooting. Now, we had the advantage of dealing with pretty primitive systems -- 'troubleshooting' often involved an oscilloscope (or the poor kids version: a latch accessorized with an LED and resistor) and an 'upgrade' like as not would involve a soldering iron---but my systems were simple enough that I had a pretty accurate mental model of how the whole system worked, and the number of subsystems that could interact to produce an effect was very limited. On modern systems with complex multiprocessing, multithreading, dozens of peripherals, operating systems providing shared services to hundreds of process and every program connected to a fault-tolerant network stack to effectively imfinite other computers that may or may not be standards compliant or even malicious. My childhood mental model of "well this address line should be going high if the data is being sent to ..." is almost quaint in the face of that.

Still, I've noticed that the Google/SO approach to troublehooting is, all too often, to collect an exhaustive set of things to try, and begin trying them. If you discover one that works, say yay!, and move on to the next problem. If you're very, very nice, post that it worked so that the solution can be lifted marginally higher in the queue for the next person. My students (who, admittedly are very inexperienced, I suspect this behaviour becomes less prevalent later) seem to spend very little time on what was a critical first step for me: hypothesize about what things could possibly be causing the problem and then come up with an experiment (often involving a simplified program or using only a subset of the system). My initial tests were rarely to isolate the problem: they were to either eliminate or comfirm a class of problems as I successively isolated the specific cause (ok, so it remains if I move it to another block of memory. Maybe it's a race condition? Ok, what if I force this test high, then there won't be any branching in this code block ---that's vaguely recalled from a problem that came down to needing a NOP in one branch path to avoid a fencepost error in some probably over-optimized code). The benefit was that, after a few months of troubleshooting like that, you kmew your system absurdly well. Conversations within the tiny community of fellow travellors (there were about a half-dozen in my high school of more than a thousand students) were heroic tales of bugs run to ground that we all learned from and tried ourselves.

Unfortunately, it's not really possible to learn a system that well any more, they're too complex. But I wonder if the ease of just typing the error message into Google means this generation don't learn the application of the scientific method that good troubleshooting really is. Because, for many of my students, it seems as though if the answer isn't on SO, then it will forever remain a mystery.

> Experts' Exchange, which was basically an earlier version of Stack Overflow

Expert Sex Change was garbage, though. If it hadn't been as terrible as it was throughout its life, Stack Overflow wouldn't have taken off nearly as easily or as well as it did. I mean, I like to grouse as much as the next graybeard over how SO has gone downhill - and it has - but it's still miles and miles better than the metaphorical and deeply unmourned Superfund site that predeceased it.

Borland Turbo C - how I loved that program!

To actually learn C (not ++) I used Bjarne Stroustrup's C all the way. I think it was 150 pages of book with 10 pages of index, not exactly a heavy book, probably no larger than a 13" screen 'ultrabook' and I took it everywhere.

Back then we had attention spans longer than a goldfish, so studying a book that was so concise was the way to go, not to skim search results, copy and paste.

Before then with the BBC Micro again there were just the two manuals, the one it came with and some advanced one. The ZX81 was okay with just the manual it came with.

Computer magazines were actually how you learned new stuff, or at least saw stuff that you wanted to do, even if the reality was typing in hex-dumps.

As for attention spans:

https://geneticliteracyproject.org/2016/07/25/another-modern...

A Microsoft study in 2013 said the attention span of a goldfish is 9 seconds, whereas we had attention spans of 12 seconds in 2000 and 8 seconds in 2013.

There is a lot of 'averages' here, however, we have changed how we expect to learn things. I have no idea whether it is 'needle, haystack' or the other way around for commands I use daily. We just remember where to find stuff on the internets rather than in our own grey matter.

In the early 1980s I was a starving artist in Denver, Colorado. I was trying to simultaneously finish a physics degree, work a full-time job, learn martial arts, write and perform avant-garde electronic pop music, and help my girlfriend raise a small child.

(I continued this general strategy of doing way too much stuff and getting way too little sleep all the time until it all came crashing down on me in 2004, and my life changed drastically and permanently.)

Apple released the Mac, and I fiddled around with it. I really loved MacPaint, but there was no way I could possibly scrape together enough money for a Mac. They were twenty-five hundred dollars. It might as well have been a million. Some years my annual income didn't break $5,000.

Nevertheless, my newfound fascination with digital painting led me to start reading everything I could find about programming, mostly in books and hobbyist magazines. There was a plethora of geeky computing magazines in the middle of the 1980s.

Eventually, with my girlfriend's help, I scraped together enough money to buy a bargain-basement Commodore 128. It wasn't a Mac, but it had a BASIC interpreter built in and it could display graphics. They were 8-bit color graphics with huge, fat pixels on a 320x240 screen, but they were graphics.

I started buying COMPUTE! Magazine. Each issue shipped with a piece of software in it, in the form of a BASIC program printed in a column in the magazine. You could type it into the Commodore and presto! You had a new piece of software!

The transformative event for me was typing in an assembler written in BASIC. After that I could write programs in assembly language. I bought a big fat book that documented the Commodore memory map, listing everything in the machine's memory along with all the addresses. It listed the entry-points for all the built-in BASIC subroutines. I could write machine-language programs that used the built-in BASIC graphics routines!

I wrote a crappy little paint program that I called "ChocolatePaint". It was horrible. Trying to write MacPaint for an 8-bit 320x240 screen and a cheap joystick is a terrible idea. However, I also discovered Conway's Life and got sucked into a black hole of cellular automata.

I spent months on successive versions of a 2D cellular automata program that ran several sets of rules simultaneously on the same grid. There were N sets of rules. Each cell of the grid obeyed all N sets of rules at the same time. The color and text-character displayed at each cell depended on the ruleset that caused it to be considered alive (all dead cells were rendered as empty black squares).

I would stay up too late at night fiddling with my cellular automaton, then fall into bed thinking about ways to improve it until I fell asleep, leaving the thing running overnight. I would get up too early in the morning and rush in to see what the program had produced. Sometimes it was a black wasteland with maybe a few live cells here and there. Sometimes it was a riot of color as some ruleset had mostly taken over, occasionally providing fertile habitats for secondary rulesets to thrive in.

One day, when I was juggling work on a graduate degree in psychology, songwriting, working in a bookstore, and this cellular automata craziness, while exploiting the bookstore job to read every book and magazine title that had anything whatsoever to do with programming, I learned that my girlfriend was going to have my child. Uh-oh. Sub-$10K income looked even less attractive than before.

My mother, a member of Mensa, sent me an ad from the Mensa Bulletin asking for people to apply to Apple Computer to work as technical writers. I said to myself, "why not?" And sent in my application.

To my complete astonishment, Apple flew me out to Cupertino to interview, then made me a job offer that would multiply my income by a factor around ten, and that would represent a whole number multiple of the most money I had ever made in a year in my life. To work with and on programming systems for Apple products!

I said, "sure!"

I officially started work in Cupertino on January 1, 1988, but that was a Friday. I don't remember for sure, but I imagine I didn't really start until the following Monday.

Apple drastically accelerated my self-education in programming. It had several resources that were like heaven for me:

- the Internet Apple had one of the earliest domain names assigned, and a great big chunk of IP addresses. It had a dialup network for employees that bridged to the Internet. It supported uucp. Woohoo! Apple had connections to everybody on the net and repositories of all the software anywhere that anybody thought was interesting. Oaklisp! Smalltalk-80! AT&T CFront! Eiffel! Icon! FigFORTH! MIT Scheme! Minix! GNU! I promptly downloaded every free compiler and interpreter and OS I could find and set about learning all I could about them.

- the technical library Apple had a robust library of technical books for any employee to check out. In order to ensure that its library was the best it could possibly be, it had a policy that I took full advantage of: if you went looking for a book there and they didn't have it, you could file a request for them to get it. Not only would they order a copy of the title for the library, they would order an extra copy and give it to the employee who had requested it. I spent hours in there. My collection of technical books on programming and computer science ballooned in size.

- the software library Apple had a software library with policies similar to those of the library of books, except that you couldn't go in and browse the stacks and they wouldn't give you a free copy of the software you requested (a lot of software was pretty expensive). It would, however order enough copies to ensure that you could check one out, and it would allow you to renew your checkout indefinitely. It also had archives of every piece of software that Apple had ever shipped, or that it had ever released internally. My collection of working software ballooned in size. I requested and checked out every compiler and interpreter I could find. I had old versions of Apple Smalltalk and Fabrik and everything else I could find.

- the competitive intelligence library This was Apple's library of actual computing hardware. You couldn't check out the hardware and take it home, but you could reserve time on it. If the machine was connected to the internal network you could get an account on it. They had everything. I spent hours fooling with a Xerox Star. I learned Lisp and Emacs using a Unicos account on Apple's Cray Y-MP. Later I talked someone in ATG into letting me borrow his Symbolics machine. I rolled it into my office, where it stayed for about two years until he decided he missed it and came back and got it.

That, plus lots of conversations and cooperative projects with other programmers working at Apple, is how I did it before Stack Overflow.