This period lasted quite some time. In the mid 00s it was still like this. I remember writing code in notepad and vim. Version managers like tortoiseSVN were a total game changer when it came to collaborating.
I still think learning like this is the best way to truly understand things. Neovim still my favourite IDE.
Grab BBC Basic manual (supplied with the computer) off the shelf, switch my Model B on (later Master). Within milliseconds a fresh working environment is created (ie a cursor starts flashing next to a “>”) and I’m off to the races.
Hope the tape recorder works to save my work every hour or so. Switch on my Epson fx80 to dump hard copy.
Those manuals were fantastic. I was still coding on our Beeb in the early 90s and I wanted the assembly manual. My dad ordered it from Acorn but it never arrived. Ended up going to the small claims court to get our money back.
In the late 90s, I wanted to learn x86 assembly and sent an email to Intel asking for their reference manuals. They sent four huge volumes to me for free. I've no idea whether that was a mistake, but I was very grateful.
I still can't believe any of us were able to write programs just from reading books, and I'm not sure to what extent that's even possible today. Even online documentation now seems really crappy compared to those old manuals.
Even early 2000s my experience coding was writing code, building it at my PC, copying it to a floppy, carrying it to the device I worked on
In the lab, burning the NVRAM with it, rebooting it, and seeing if it worked. Debugging meant manually typing in memory addresses into the keypad to inspect (I had the address of every global var in the system).
For deeply thought intensive tasks like “why did the system crash” I printed out pages of C code and hand-executed code to find places with invalid memory access. For example a null pointer wouldn’t segfault and print a nice stack trace, it’d just overwrite the in memory code itself.
It was laborious but lots of fun. I learned a ton about C and embedded programming
I did an independent study of C in high school in 2003.
I sat at a non-internet-connected terminal in the back of the TechED room and typed examples from the provided book into a very simple editor. Sometimes they compiled and worked. Sometimes they did not work despite being to all appearances character for character the same as the book, and I was often left with no idea why.
It was not an entirely unfamiliar experience. I had a Mattel Aquarius as a young child and spent countless hours typing games in from the back of the manual before attempting to save them to cassette.
Memories of coding in FoxPro 2.5, with the reference manual on my lap. I wasn't the original programmer, so I had to figure out another guy's copypasta.
There were BBSes back then where you could often find help from others or share code. Not just mail and magazines.
I had a project at a private bank where we couldn't use the internet - we had to turn our phones in when we checked in, had to use their computers on their network, couldn't access the outside internet... we did have access to api documents electronically thankfully. If we wanted to update a library it had to go through a big security review that took weeks.
It slowed work down a lot but was totally fine - the bank was paying us tons of money hourly.
> But something also got lost along the way, and it's that obligation to read slowly, to understand every line because there was no shortcut available
Not really sure what got "lost" here. But fundamentally nothing has really changed much, except for deeper abstractions, more powerful tools and the cost of "generating" (or producing) code approaching near zero (if you discount the cost of subscriptions to Claude/Codex, etc and the underlying costs of running those st scale).
You still have to understand, and read every line. Although now we just get tools to do so for us. But the understanding is still a requirement.
It's interesting how different people view the past. I also used to spend hours and days typing in all that BASIC code but I don't look back on it with romantic nostalgia. We were forced to do that simply because modems and floppy disks were expensive in the 1980s.
The reason magazine subscribers endured it was because most of us were kids (which means we had more free time than money) and the reward was usually a "free" game when it was done. We just mindlessly type in endless PEEK and POKE syntax which was just gibberish to get a video game out of it. (Some of the code listings were for "serious" things like spreadsheets but the vast majority was for games.) I certainly didn't learn programming or patience by typing in PEEK/POKE for seemingly-random memory locations.
And after that, magazines also offered to mail floppy disks with all the code listings for an extra price. (The selling point was "No Need To Type In The Code!")
These days, we complain when other programmers "cargo-cult" code by copy-pasting from StackOverflow (or LLM these days) without truly understanding it. Well, that's what us kids did in 1980s ... just cargo-culted the whole BASIC code listing to play a game. Sure, there were a small minority that actually studied the magazine's BASIC code line-by-line to really understand it but none of us in our computer club did that.
Just last week, I spent several hours reading the rsync C Language source code line-by-line so I could write a custom patch to add nanoseconds to the file creation dates. Dissecting that took a lot more patience and focus than typing in code listings from a magazine.
Which is why when being on UNIX, and having only vi, Emacs and XEmacs available, with basic tools like ctags, unless being lucky to work at some place paying for really expensive UNIX IDEs felt like a downgrade for folks raised in Amiga/PC world.
> Debugging, back then, was an almost physical thing. Comparing character by character what was on screen against what was printed on the page. Realizing that the "1" that looked like a lowercase "l" had tricked you for half an hour.
And the 0 and 8. And this was used by some copy-protection to try to prevent reverse engineering. Back then real debuggers (by "real debugger" I mean not just "debugging in your head": but an actual, although very minimal, debugger) were very simplistic too, and so you'd read everything line by line, keeping in your head what the program was doing, was the register contained, what subroutines would do etc. And then you'd have "tricks" by the copy protection where that line with a '0' you just analyzed a few commands before would turn, sneakily, into a '8' (maybe by a function or a side effect of a command etc.).
And when we'd spot it we'd be: "Wait dude, did you notice how sneaky it is, this actually turns the 0 into an 8, so the next this execute, everything shall be corrupt" (or something like that).
And so debuggers got enhanced: for example if anything on screen got modified, the modified value would flash than stay in green. Stuff like that.
Our tools were much more basic.
But then we learned to eat 68x00 and x86 opcodes for breakfast.
This period lasted quite some time. In the mid 00s it was still like this. I remember writing code in notepad and vim. Version managers like tortoiseSVN were a total game changer when it came to collaborating. I still think learning like this is the best way to truly understand things. Neovim still my favourite IDE.
Grab BBC Basic manual (supplied with the computer) off the shelf, switch my Model B on (later Master). Within milliseconds a fresh working environment is created (ie a cursor starts flashing next to a “>”) and I’m off to the races.
Hope the tape recorder works to save my work every hour or so. Switch on my Epson fx80 to dump hard copy.
Simpler, happier times.
Those manuals were fantastic. I was still coding on our Beeb in the early 90s and I wanted the assembly manual. My dad ordered it from Acorn but it never arrived. Ended up going to the small claims court to get our money back.
In the late 90s, I wanted to learn x86 assembly and sent an email to Intel asking for their reference manuals. They sent four huge volumes to me for free. I've no idea whether that was a mistake, but I was very grateful.
I still can't believe any of us were able to write programs just from reading books, and I'm not sure to what extent that's even possible today. Even online documentation now seems really crappy compared to those old manuals.
Memory error - it was a Seikosha dot matrix I used back then. The FX80 came later.
Even early 2000s my experience coding was writing code, building it at my PC, copying it to a floppy, carrying it to the device I worked on In the lab, burning the NVRAM with it, rebooting it, and seeing if it worked. Debugging meant manually typing in memory addresses into the keypad to inspect (I had the address of every global var in the system).
For deeply thought intensive tasks like “why did the system crash” I printed out pages of C code and hand-executed code to find places with invalid memory access. For example a null pointer wouldn’t segfault and print a nice stack trace, it’d just overwrite the in memory code itself.
It was laborious but lots of fun. I learned a ton about C and embedded programming
I did an independent study of C in high school in 2003.
I sat at a non-internet-connected terminal in the back of the TechED room and typed examples from the provided book into a very simple editor. Sometimes they compiled and worked. Sometimes they did not work despite being to all appearances character for character the same as the book, and I was often left with no idea why.
It was not an entirely unfamiliar experience. I had a Mattel Aquarius as a young child and spent countless hours typing games in from the back of the manual before attempting to save them to cassette.
My first computer from the 80's had autocomplete: ZX80.
Was only BASIC, but needed as there wasn't any way to save...
Memories of coding in FoxPro 2.5, with the reference manual on my lap. I wasn't the original programmer, so I had to figure out another guy's copypasta.
There were BBSes back then where you could often find help from others or share code. Not just mail and magazines.
I had a project at a private bank where we couldn't use the internet - we had to turn our phones in when we checked in, had to use their computers on their network, couldn't access the outside internet... we did have access to api documents electronically thankfully. If we wanted to update a library it had to go through a big security review that took weeks.
It slowed work down a lot but was totally fine - the bank was paying us tons of money hourly.
> But something also got lost along the way, and it's that obligation to read slowly, to understand every line because there was no shortcut available
Not really sure what got "lost" here. But fundamentally nothing has really changed much, except for deeper abstractions, more powerful tools and the cost of "generating" (or producing) code approaching near zero (if you discount the cost of subscriptions to Claude/Codex, etc and the underlying costs of running those st scale).
You still have to understand, and read every line. Although now we just get tools to do so for us. But the understanding is still a requirement.
In VB6 I just scrolled the autocomplete dropdown in the 2005 IDE to find what's possible + Some random answer from codeproject.com
The good times...
Copying scripts from books is still the best way to learn, and still the only choice in some areas.
Author is talking about manually typing in by hand the hundreds (or even thousands) of lines of code from magazines like COMPUTE!: https://www.google.com/search?q=compute%21+magazine+code+lis...
It's interesting how different people view the past. I also used to spend hours and days typing in all that BASIC code but I don't look back on it with romantic nostalgia. We were forced to do that simply because modems and floppy disks were expensive in the 1980s.
The reason magazine subscribers endured it was because most of us were kids (which means we had more free time than money) and the reward was usually a "free" game when it was done. We just mindlessly type in endless PEEK and POKE syntax which was just gibberish to get a video game out of it. (Some of the code listings were for "serious" things like spreadsheets but the vast majority was for games.) I certainly didn't learn programming or patience by typing in PEEK/POKE for seemingly-random memory locations.
To help reduce the inevitable typos and frustrating mistakes made by readers, the later magazines had a "checksum" utility to help: https://en.wikipedia.org/wiki/The_Automatic_Proofreader
And after that, magazines also offered to mail floppy disks with all the code listings for an extra price. (The selling point was "No Need To Type In The Code!")
These days, we complain when other programmers "cargo-cult" code by copy-pasting from StackOverflow (or LLM these days) without truly understanding it. Well, that's what us kids did in 1980s ... just cargo-culted the whole BASIC code listing to play a game. Sure, there were a small minority that actually studied the magazine's BASIC code line-by-line to really understand it but none of us in our computer club did that.
Just last week, I spent several hours reading the rsync C Language source code line-by-line so I could write a custom patch to add nanoseconds to the file creation dates. Dissecting that took a lot more patience and focus than typing in code listings from a magazine.
This period latest until the mid 00s. I remember trying to learn Java in the early 00s and it was really hard and I needed a textbook.
No blogs, no SO, no autocomplete, crappy IDEs, no AI, etc...
I miss that difficult focused learning. The smallest successes felt like huge accomplishments.
Maybe not 80s, but I vaguely remember visual basic 4 having autocomplete...
Which is why when being on UNIX, and having only vi, Emacs and XEmacs available, with basic tools like ctags, unless being lucky to work at some place paying for really expensive UNIX IDEs felt like a downgrade for folks raised in Amiga/PC world.
> Debugging, back then, was an almost physical thing. Comparing character by character what was on screen against what was printed on the page. Realizing that the "1" that looked like a lowercase "l" had tricked you for half an hour.
And the 0 and 8. And this was used by some copy-protection to try to prevent reverse engineering. Back then real debuggers (by "real debugger" I mean not just "debugging in your head": but an actual, although very minimal, debugger) were very simplistic too, and so you'd read everything line by line, keeping in your head what the program was doing, was the register contained, what subroutines would do etc. And then you'd have "tricks" by the copy protection where that line with a '0' you just analyzed a few commands before would turn, sneakily, into a '8' (maybe by a function or a side effect of a command etc.).
And when we'd spot it we'd be: "Wait dude, did you notice how sneaky it is, this actually turns the 0 into an 8, so the next this execute, everything shall be corrupt" (or something like that).
And so debuggers got enhanced: for example if anything on screen got modified, the modified value would flash than stay in green. Stuff like that.
Our tools were much more basic.
But then we learned to eat 68x00 and x86 opcodes for breakfast.