If there are any older devs on here, (pre StackOverflow) what did debugging look like back then? Rifling thru language manuals?? Diving into source code ??

I'm super curious

So, going waaaay back, printing the code off on a wide carriage printer and desk checking the code line by line. Then later on I started putting printf() statements in my functions (top of function, bottom of function, start of while, etc). And yes, manuals. The C Programmers Bible, for example. It was his though, because you learned your code.

Visual Studio.Net (2003) using a barely working Intellisense/Autocomplete against C# in .Net Framework 1.1, with O’Reilly “C# In a Nutshell” and MSDN Online.

It was awesome.

Tons of breakpoints and modal popups, variable watchers and logs all over the place, while we traced the code line by line trying to find the "one thing" that wasn't working...
It got so time-consuming to set up that we actually chose to make a branch with all that in place, 'cause maintaining the diff between that beast and the main branch was easier than making it from scratch and tearing it down every time...
Oh, how I adore unit tests!

Sifting through code line by line, paying extra attention to the error logs, and outputting variables at different locations to ensure they were as expected until you found the issue.

@FrodoSwaggins Time is evil. Not to get off topic but I worked on a system where it would report 13:23:60. This was due to it incrementing the seconds but before incrementing the minute and resetting the seconds back to 00. I thought it was a fluke, but it had several boundary issues like 13:60:00 and 24:00:00 over the course of a year. I had to fix the datetime in extract so other systems could consume the data.

Debuggers could always single step. If that wasn't an option, having a debug_log() function that added trace information in debug mode, but was optimized away in release mode, was always an option.

And with "always" I mean: at least since 1990. 😊

Going through the source and understanding what exactly it was doing. Chuck Norris debugging, which is still extremely helpful today for non-reproducible or timing errors.

I didn't use a printer for debugging because the noise of my dot matrix printer was insane.

Otherwise, a lot of printf and reading language books, and avoiding too clever code in the first place. When it HAD to be super clever because of speed, then it was first coding obvious albeit slow, keeping the slow variant, making the code clever, running both variants and making sure the results were the same.

Guess what, that was part of the fun because it wasn't for everyone. Not like today where some liberal arts students can click their Skynet together.

But we already had coffee! Without sugar though because sugar was still made out of salt back then.

Debugging? Stackoverflow? Son, if you're using the later to do the former you're fairly confused.

Regardless, way back then, before the internet, us devs had to (gasp!) RTFM.
Debugging was using the system debugger (there wasn't yet the concept of an ide). And if things still didn't work, we consulted other devs. I worked at Texas Instruments and they had a tech library but it was full of books with theories, formulas and lots of scholarly discussions - you couldn't find a code snippet to save your life.

We have it pretty good these days

@rantalicious whole team code reviews were as brutal as whole company deployment meetings (precursors to change meetings/CAB meetings).