My programming career dates back to the '70s, so I can tell you what programmers did back then from my experience: examined core dumps, inserted "print" statements, desk-checked (manually read through) code with a colleague.
We didn't have debuggers per se, but we could step through code one instruction at a time and examine memory. On the PDP minicomputers you would do that from the front panel with switches and lights.
I had to read assembly code and dis-assemble memory contents into assembly routinely back then. I'm sure Dennis Ritchie did that too, that skill was part of the toolbox.
While TDD became a buzzword and cult much later, in the companies I worked at back then we often/usually had to submit a test plan with code to run the tests for any non-trivial code. At my first job (Nike, 1979) we called that code a test harness, more or less the same thing as modern unit tests without the automation. Most companies I worked for through the '80s would run a parallel hardware system for testing/staging, and we worked with business and systems analysts who could verify correct implementation of business rules and look for performance bottlenecks (more of an issue back then compared to today).
Brian Kernighan wrote a book about his days at Bell Labs that covers the development of Unix and C.