5 ms·

For programmers that were coding before good search engines: what did you do when you wanted to look up an error, etc back then? Crack open a tome for the langu

For programmers that were coding before good search engines: what did you do when you wanted to look up an error, etc back then? Crack open a tome for the language? Just curious as I can't imagine it was easy.

teh_klev 10y ago
For me it was Altavista and Usenet and DeJaNews [0] (which indexed usenet). Before that it was hard copy manuals and phone-a-friend. [0]: https://en.wikipedia.org/wiki/Google_Groups#Deja_News https://en.wikipedia.org/wiki/Google_Groups#Deja_News
mlvljr 10y ago
You get MSDN on 3+ CDs, do a full install and make couple searches using the built-in search.
BuckRogers 10y ago
For the most part you were on your own. I used books myself since I didn't have colleagues back then. But software was in many ways simpler. The complexity was in squeezing out performance rather than piles of abstraction layers on top of one another. Knowing the hardware was more important and that was gleamed through trial and error. The internet enabled the complexity that made software development dependent on it.
grifter2000 10y ago
Honestly? Yeah. I printed a lot of man pages and docs out, kept my references closer at hand than I do now, and made a lot of handwritten notes to help bury peculiarities and API into my swiss cheese brain.
reitanqild 10y ago
I might not be the best qualified but 1. Yes, 2. Wrote around it.
dozzie 10y ago
Yes, the general rule was to actually understand what the error means, and if that didn't solve the problem, where it occurred and how did the thing get in the erroneous state (the thing called "debugging").
psyklic 10y ago
The errors I need Google for are almost universally caused by third-party libraries. Back in the day, your software relied on significantly fewer third-party libraries, and/or you wrote the libraries yourself in-house. Languages had much smaller standard libraries. And, you always had direct access to the lowest levels of your system without OS interference, so you could work around or debug anything. So, I had no trouble without Internet just having K&R and manuals for whatever I was interfacing with.
tyingq 10y ago
If it was time sensitive, and a show-stopper error, I usually just had to solve the problem using a different approach/library/tool. Sometimes you could find someone on irc to help, but that was pretty hit or miss. If there was time, I would post on either a bbs, or usenet (comp.lang.*), and hope somebody else had the answer. The ecosystem was better documented at the time though. Solaris manuals, for example, were very extensive. You didn't have the litany of third party tools that you do today. So, problems that weren't explained in the manuals weren't as common.
csixty4 10y ago
Yeah. We all had bookshelves in our cubicles and we knew who had what book. Between all the people on the team, we had the answer to pretty much everything.
Someone 10y ago
There are at least two periods 'before good search engines'. I guess there was a time in the 1950s/1960s when you asked the guy sitting in the next room, who wrote the software, what the error meant, or where you simply read the source code or disassembled the code to figure it out. When computers became more common, but weren't powerful enough yet for storing electronic documentation, you didn't crack open the tome; you already had it open (and it was more often a tome on the OS than one on the language) You also typically had a printed list of error codes on your desk. When memory became less scarce, you would see header files with extensive (for the time) documentation, and there were tools to look up API calls, error codes, etc. (I think Windows or Visual Studio still ship with one) When CD-ROMs became common, you had documentation on CD. Later, when hard disks outgrew CD-ROMs, that data moved to hard disk, because that was faster, and multi-CD setups became common-place. Those CDs later moved to the web. That often made searches even faster (for example, I remember searching Apple's or Microsoft's site being faster than searching a locally installed MSDN (yes, MSDN was an application before it became a web site) or Apple's documentation for a while) Also, I read release notes front to back, and used to read almost all API documentation. I think that was fairly common. Without the likes of HN to distract you, there was plenty of time to do that :-) Since search engines weren't that good, it also was useful. If you didn't know the name of an API call or at least that of a technology, it was almost impossible to find it.
- passivepinetree 10y ago
  shudders
pbnjay 10y ago
I remember actually going to my local library and finding some detailed technical books (in my case DOS Interrupts I think), and reading a lot to find out WTF was going on.
- ArkyBeagle 10y ago
  Our team lead bought us all a copy of "Advanced MS DOS" for that. We'd have "Taylor Thursdays" where we'd all eat lunch close to a Taylor's Books and spend an hour or two scouring the shelves. I did once go to the library for a reference to a 1950s book on relevance trimming of search indexing - probably about 10% of "MapReduce".

teh_klev 10y ago

For me it was Altavista and Usenet and DeJaNews [0] (which indexed usenet). Before that it was hard copy manuals and phone-a-friend. [0]: https://en.wikipedia.org/wiki/Google_Groups#Deja_News https://en.wikipedia.org/wiki/Google_Groups#Deja_News

mlvljr 10y ago

You get MSDN on 3+ CDs, do a full install and make couple searches using the built-in search.

BuckRogers 10y ago

For the most part you were on your own. I used books myself since I didn't have colleagues back then. But software was in many ways simpler. The complexity was in squeezing out performance rather than piles of abstraction layers on top of one another. Knowing the hardware was more important and that was gleamed through trial and error. The internet enabled the complexity that made software development dependent on it.

grifter2000 10y ago

Honestly? Yeah. I printed a lot of man pages and docs out, kept my references closer at hand than I do now, and made a lot of handwritten notes to help bury peculiarities and API into my swiss cheese brain.

reitanqild 10y ago

I might not be the best qualified but 1. Yes, 2. Wrote around it.

dozzie 10y ago

Yes, the general rule was to actually understand what the error means, and if that didn't solve the problem, where it occurred and how did the thing get in the erroneous state (the thing called "debugging").

psyklic 10y ago

The errors I need Google for are almost universally caused by third-party libraries. Back in the day, your software relied on significantly fewer third-party libraries, and/or you wrote the libraries yourself in-house. Languages had much smaller standard libraries. And, you always had direct access to the lowest levels of your system without OS interference, so you could work around or debug anything. So, I had no trouble without Internet just having K&R and manuals for whatever I was interfacing with.

tyingq 10y ago

If it was time sensitive, and a show-stopper error, I usually just had to solve the problem using a different approach/library/tool. Sometimes you could find someone on irc to help, but that was pretty hit or miss. If there was time, I would post on either a bbs, or usenet (comp.lang.*), and hope somebody else had the answer. The ecosystem was better documented at the time though. Solaris manuals, for example, were very extensive. You didn't have the litany of third party tools that you do today. So, problems that weren't explained in the manuals weren't as common.

csixty4 10y ago

Yeah. We all had bookshelves in our cubicles and we knew who had what book. Between all the people on the team, we had the answer to pretty much everything.

Someone 10y ago

There are at least two periods 'before good search engines'. I guess there was a time in the 1950s/1960s when you asked the guy sitting in the next room, who wrote the software, what the error meant, or where you simply read the source code or disassembled the code to figure it out. When computers became more common, but weren't powerful enough yet for storing electronic documentation, you didn't crack open the tome; you already had it open (and it was more often a tome on the OS than one on the language) You also typically had a printed list of error codes on your desk. When memory became less scarce, you would see header files with extensive (for the time) documentation, and there were tools to look up API calls, error codes, etc. (I think Windows or Visual Studio still ship with one) When CD-ROMs became common, you had documentation on CD. Later, when hard disks outgrew CD-ROMs, that data moved to hard disk, because that was faster, and multi-CD setups became common-place. Those CDs later moved to the web. That often made searches even faster (for example, I remember searching Apple's or Microsoft's site being faster than searching a locally installed MSDN (yes, MSDN was an application before it became a web site) or Apple's documentation for a while) Also, I read release notes front to back, and used to read almost all API documentation. I think that was fairly common. Without the likes of HN to distract you, there was plenty of time to do that :-) Since search engines weren't that good, it also was useful. If you didn't know the name of an API call or at least that of a technology, it was almost impossible to find it.

passivepinetree 10y ago
shudders

pbnjay 10y ago

I remember actually going to my local library and finding some detailed technical books (in my case DOS Interrupts I think), and reading a lot to find out WTF was going on.

ArkyBeagle 10y ago
Our team lead bought us all a copy of "Advanced MS DOS" for that. We'd have "Taylor Thursdays" where we'd all eat lunch close to a Taylor's Books and spend an hour or two scouring the shelves. I did once go to the library for a reference to a 1950s book on relevance trimming of search indexing - probably about 10% of "MapReduce".