4 ms·

I'm self-taught, and now in my 50s. I started programming when I was 10, in 1976. In those earliest days of consumer-class computers, there wasn't really a dev

I'm self-taught, and now in my 50s. I started programming when I was 10, in 1976. In those earliest days of consumer-class computers, there wasn't really a developed market for practical programming books. However, the manuals that came with software or OSes were quite well-written. There were a few magazines, too, like BYTE and Dr. Dobbs Journal, that published source code -- always the best way to learn! It helped, too, that my dad was a programmer. I learned most of the basics about computer architecture, binary logic, algorithms, etc., from talking with him. There were local user groups, though most of the folks were enthusiasts, not necessarily programmers. By the early 80s, I was reading the C manual by K&R and other books on practical programming, and trying things on my home CP/M system (Heathkit H89). If I had problems (and I often did), I simply had to experiment, read more, think more, debug more. I first got online around 1980 -- via dial-up BBSes, then the early Internet (ARPAnet), and USENET. While you generally couldn't search for answers/code the way you can now, you could browse, and you could certainly ask people who knew, or at least could offer suggestions. Finally, I think it's been an advantage that for most of my programming life, I've used Unix, and most of the versions I used included source, which is always educational.

DonHopkins 9y ago
I loved Dr. Dobb's Journal too, and I also really looked forward to each delicious issue of Creative Computing as a kid! Like so many others, I read the Adventure source code and typed in the Star Trek source code. I also loved all the Beagle Bros software and programming tools, and especially their catalogs and ads. (And NO, they were definitely NOT "Brogrammers", they were freaks!) https://en.wikipedia.org/wiki/Beagle_Bros https://en.wikipedia.org/wiki/Beagle_Bros http://beagle.applearchives.com/ http://beagle.applearchives.com/ http://beagle.applearchives.com/Catalogs/Tip_Book_1(Searchable).pdf http://beagle.applearchives.com/Catalogs/Tip_Book_1(Searchab...
- dhimes 9y ago
  +1 Creative Computing
  - lanstin 9y ago
    +1 for typing in the Star Trek. Typing in source code is slower than downloading some PyPi thing but it lets you learn faster. At least at first.
- sitkack 9y ago
  Dear Lazyweb, if someone comes across the "Dr. Dobb's Developer Library DVD" please donate a copy to the Internet Archive. I contacted the new owners of Dr. Dobbs (UBM) and they actually sold the last version they had. No backup. Weren't interested in selling any more copies. http://www.drdobbs.com/tools http://www.drdobbs.com/tools
ajarmst 9y ago
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.
TheOtherHobbes 9y ago
Also of similar vintage. True story about learning C on an Atari ST: I bought a cheap compiler, tried to use one of the standard library functions, couldn't work out why it wasn't working. Used the debugger to single-step through the 68k machine code it had generated. Still couldn't see why it wasn't working, because what it was doing didn't make sense. Typed out a letter - dot-matrix printed on paper - and posted it, with an envelope and a stamp and all, to the compiler manufacturer. Got a letter back - hand-typed on headed note paper and signed with a pen - saying: "Sorry, we haven't implemented that function yet." Whole cycle took about two weeks. I prefer having SO, Google and GitHub to work with.
cm2187 9y ago
I think they key is your dad being a programmer. My first missed encounter with programming was when I was a teenager in the 90s. I sort of wanted to do more with these machine but wasn't sure where to start. My parents weren't particularly IT savvy (though we had home computers since the Mac SE) and weren't keen for me to do something else than outdoor activities. I still managed to get them to buy me a copy of code warrior, as I kind of understood this was to create software. Then found myself in front of a white text editor. Had never even heard of C and that was a few years before the internet. Never went beyond that until college. Kids today are spoiled...
- spc476 9y ago
  > I think they key is your dad being a programmer. I don't think so. My experience was pretty much the same as jslabovitz's, just without the progamming dad. I started programming in 1984 and pretty much only had books, manuals, and magazines to work from. I only had one friend who had a computer and it wasn't the same as mine (and in the 80s, there were scores of different CPUs and operating systems to choose from) so I was more or less on my own. I still miss the BYTE magazine with the Robert Tinney covers ...
  - cm2187 9y ago
    But somehow someone must have pointed you in the direction of these books and magazines. I wasn't even aware there were programming magazines then. Also in the early 80s using a computer pretty much meant programming. In the early 90s (my youth) computers all had some form of GUI and lots of shareware, and computer magazine weren't really talking about programming.
    - js2 9y ago
      I was born in 71 and my dad got us an Apple II in 1980. He wasn't a programmer, but the Apple II came with a full set of hardware and software manuals. We also had a Byte subscription. I taught myself Applesoft Basic, then 6502 assembly. I distinctly remember having printouts of assembly listings spanning dozens of pages spread across the floor which I annotated.
mondainx 9y ago
I can echo most of that as well (also almost 50). Books, magazines, and good old trial-n-error methods.

DonHopkins 9y ago

I loved Dr. Dobb's Journal too, and I also really looked forward to each delicious issue of Creative Computing as a kid! Like so many others, I read the Adventure source code and typed in the Star Trek source code. I also loved all the Beagle Bros software and programming tools, and especially their catalogs and ads. (And NO, they were definitely NOT "Brogrammers", they were freaks!) https://en.wikipedia.org/wiki/Beagle_Bros https://en.wikipedia.org/wiki/Beagle_Bros http://beagle.applearchives.com/ http://beagle.applearchives.com/ http://beagle.applearchives.com/Catalogs/Tip_Book_1(Searchable).pdf http://beagle.applearchives.com/Catalogs/Tip_Book_1(Searchab...

dhimes 9y ago
+1 Creative Computing
- lanstin 9y ago
  +1 for typing in the Star Trek. Typing in source code is slower than downloading some PyPi thing but it lets you learn faster. At least at first.
sitkack 9y ago
Dear Lazyweb, if someone comes across the "Dr. Dobb's Developer Library DVD" please donate a copy to the Internet Archive. I contacted the new owners of Dr. Dobbs (UBM) and they actually sold the last version they had. No backup. Weren't interested in selling any more copies. http://www.drdobbs.com/tools http://www.drdobbs.com/tools

ajarmst 9y ago

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.

TheOtherHobbes 9y ago

Also of similar vintage. True story about learning C on an Atari ST: I bought a cheap compiler, tried to use one of the standard library functions, couldn't work out why it wasn't working. Used the debugger to single-step through the 68k machine code it had generated. Still couldn't see why it wasn't working, because what it was doing didn't make sense. Typed out a letter - dot-matrix printed on paper - and posted it, with an envelope and a stamp and all, to the compiler manufacturer. Got a letter back - hand-typed on headed note paper and signed with a pen - saying: "Sorry, we haven't implemented that function yet." Whole cycle took about two weeks. I prefer having SO, Google and GitHub to work with.

cm2187 9y ago

I think they key is your dad being a programmer. My first missed encounter with programming was when I was a teenager in the 90s. I sort of wanted to do more with these machine but wasn't sure where to start. My parents weren't particularly IT savvy (though we had home computers since the Mac SE) and weren't keen for me to do something else than outdoor activities. I still managed to get them to buy me a copy of code warrior, as I kind of understood this was to create software. Then found myself in front of a white text editor. Had never even heard of C and that was a few years before the internet. Never went beyond that until college. Kids today are spoiled...

spc476 9y ago
> I think they key is your dad being a programmer. I don't think so. My experience was pretty much the same as jslabovitz's, just without the progamming dad. I started programming in 1984 and pretty much only had books, manuals, and magazines to work from. I only had one friend who had a computer and it wasn't the same as mine (and in the 80s, there were scores of different CPUs and operating systems to choose from) so I was more or less on my own. I still miss the BYTE magazine with the Robert Tinney covers ...
- cm2187 9y ago
  But somehow someone must have pointed you in the direction of these books and magazines. I wasn't even aware there were programming magazines then. Also in the early 80s using a computer pretty much meant programming. In the early 90s (my youth) computers all had some form of GUI and lots of shareware, and computer magazine weren't really talking about programming.
  - js2 9y ago
    I was born in 71 and my dad got us an Apple II in 1980. He wasn't a programmer, but the Apple II came with a full set of hardware and software manuals. We also had a Byte subscription. I taught myself Applesoft Basic, then 6502 assembly. I distinctly remember having printouts of assembly listings spanning dozens of pages spread across the floor which I annotated.

mondainx 9y ago

I can echo most of that as well (also almost 50). Books, magazines, and good old trial-n-error methods.