Yeah, I'll never forget pirating Turbo Pascal off of AOL in the 90s, going to my local library and taking out a book about Turbo Pascal so I could learn what I could do with it. Ended up coding a program that embedded metadata for all of Rush's songs, their titles, and how long they were, so that you could plan out a mixtape of just Rush's songs. Even allowed you to specify what kind of tape you had, so you could adjust each side, whether it was 45 minutes or 30 minutes, things like that. It was called Rush Mixtape Creator, and I shared the compiled binary on Usenet. Got emails about it as long as six years later asking me to make changes and update it. It was the first actual program I ever distributed. 1995.

Coding was different back then.

The thing that I really liked was that you felt like you were programming for the hardware and not really for an OS. Most systems ran a single program at a time so you pretty much had full control except for interrupts. On DOS TSR (terminate, stay resident) interrupt handlers could also do amazing things.

Knowing a lot about my personal computer (Atari 400 and later Atari ST) made it so easy to do work on embedded systems as a student intern. Without internet, learning about your hardware/ROM was paramount from magazines and word-of-mouth.

Another thing that I learned from that time is how to make designs fast and small. This is a skill that's not really taught, shared, or practiced much and makes a huge positive impact on a codebase keeping it light on abstraction depth and high on flexible capability. Huge improvement to maintainability and extension into unforeseen directions too.

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.

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.

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.

I memorized the z80 instruction in hex and would code Basic and data 3E, 15, CD, 00, C0, etc just as if it was readable and wrote many games with that. It was nice income for a 10 year old kid in the 80s and even better after. It does slightly suck more now, but AI does help making it similar; focus on the important parts, not this garbage around it.

You can always just use vim, no plugins, and a book. No one said that one must use a fancy IDE and online stuff.

Yeah, all the computer science students in the dorms would collaborate on homework assignments, but I was a non-traditional student living in a small home near the college campus, so no interaction on that front, unless no one in the dorms was able to solve something, then I'd get a phone call and would try to coach people through the solution over the phone, or would walk to the lab, printout in hand....

Failed the 301 Systems Programming class because C on my NeXT Cube was sufficiently different from the compiler in the labs and I never managed to work out how to bridge that gap mentally....

Information was so much more scarce back then. Made programming feel like a black art. I remember when I learned about overlays in Turbo Pascal, it felt like I learned a new spell :)

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.

Dont forget: Back then, after shoving tons of floppy disks (later 600MB CDs) for installing just the IDE and the compiler etc., you had to shovel another tower of media into the machine just to get the "help/doc" function installed :-D

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

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.

> 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...

My first computer from the 80's had autocomplete: ZX80.

Was only BASIC, but needed as there wasn't any way to save...

Trends will come and go but vim will always be here.

Copying scripts from books is still the best way to learn, and still the only choice in some areas.

man studio and the like were really helpful trying to figure out what something did in a piece of code

Maybe not 80s, but I vaguely remember visual basic 4 having autocomplete...

We had SWAG for pascal

This also marked peak IQ by humans developers...

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.

> 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.

Software was way simpler back then.

Nothing would get me more frustrated than copying code from a magazine for it to not work because they published something wrong.

The more sophisticated magazines had CRC codes after every line, so you could know where in the code you has mistyped.

[flagged]

[dead]