I'm of the opinion that not googling stuff means you're not a proper engineer.
And from what I've seen, those who don't google consistently also fail to understand the answers they find when they do google things. It is, in fact, an essential skill.
I’ve asked pre-internet programmers and they said they used to keep reference books at their desk or even a small library/book room at their employers.
I’ve heard some government contractors can’t google because they work on non-internet connected computers. They probably keep a lot of books.
Starting around 8th grade, I would walk to the recently opened Barnes and Noble with a pen and notepad and hand copy material from programming books I couldn't afford, then walk back home and try the stuff out in Turbo C. Rinse, repeat.
I haven't looked anything up in a book on programming in a long time, but I'm not really a software engineer presently. While I rely on Google in general and stack overflow in particular, I don't believe everything is on the Internet. I went through a period where I started to think everything was, but in recent years I realized it isn't.
And just making the decision to type things into Google is far from the ability to search effectively. Increasingly search engines will converge on a bad answer for a given question because it's the most popular. You just cannot assume that the correct solution is going to be prominent, because once another one has critical mass, it cannot be dethroned. The result that sounds just barely plausible enough to fool the average person making the search (not the average programmer) wins, and often it's terribly wrong.
A friend works at a military contractor doing (effectively) windows GUIs for power system controls. His only access to an internet-connected computer is on his breaks, where he has to wait in line to use one of a very small number of computers in a special room to google things.
I don't think he has books, but he has an enormous amount of documentation (something like the whole MSDN library, a bunch of internal documentation and reference info, and other documentation) installed on his computer.
I've never worked pre-internet. In fact, I've had internet access in all of my jobs, but I've definitely worked pre-"internet was a useful source for searching for answers to programming questions". I mean, we had Usenet, and you could ask a question, but we didn't have search engines that were useful in that capacity.
I definitely had a lot of books, but actually the vast majority of my information came from man pages, RFCs and specs. I actually learned C++ by reading the spec -- I've never read any C++ book in my life, even though I was a professional C++ programmer for at least 10 years. For learning the STL, I did it by reading the source code!
Probably the biggest thing I miss in the age of Google is that offline documentation is getting hard to find. One of the reasons I chose Rust for my latest side project is that it's extremely easy to install offline information for virtually everything.
I like doing web searches searches and Stack Overflow is really stupendously awesome. Especially when I'm working in a new language or framework, I can find idiomatic solutions to problems without having to read through thousands of lines of source code. However, I do think that newer programmers today are missing out when they don't learn how to search primary sources to get their answers.
If you have a question about how the language works, it really does pay off to look at the spec. In doing so, you learn about things in a larger context. I'm always grateful for SO answers that have links to primary sources like specs in their answers, but I've noticed that my younger colleagues almost never click on those links. When they have the answer they want, they are back to their own code. Often they miss important nuances because they are too focused on getting the answer.
Similarly, I have found that there is often a huge reluctance to read source code. A colleague once joked that he used dependencies so that he didn't have to read the source code. It's funny because it's true ;-) However, if you at least try to answer your questions first by looking at the source code for a dependency, then it will tell you a lot about that dependency (mostly: OMG! We need to ditch this ASAP! ;-) )
I used to have a collection of hundreds of RFCs on my computer. Really, anything that is about the internet has an RFC (or did back in the day, anyway). These days, even I'm lazy and don't bother to maintain offline collections of this information. However, it is worrying that I often run into developers who build very complex internet applications and don't even know what an RFC is let alone use them to learn how they should build their systems. They will have very ingrained opinions on how build things, but they have no idea how the HTTP protocol works, for example. Discussions on the topic of how to design something usually results in snippets of blog posts obtained through Google searches, rather than pointing to the relevant RFC and saying, "It works like X so we need to do Y". Negotiation of how to proceed often involves considerable heated discussion about which notable internet pundit we should trust the most.
Yeah, this is an "old programmer rant" ;-) However, if I could wave a magic wand and get younger programmers to all add something to their arsenal of tricks it would be to read primary sources early and often.
> we didn't have search engines that were useful in that capacity.
I remember that. I think it was a combination of there not being good reference websites in some cases, not good question sites in others, and search engines generally being both less good and having less of those sites to index.
I specifically remember finding sites that were goldmines for certain topics, and hoarding them in my bookmark list of useful resources.
RFCs are great and definitely under utilized. I was working on some stuff with CORS and Cookies at my last job and reading through portions of some RFCs really helped me solve my problems and understand how CORS works.
I have a friend who used to work for the defence civil service and one time he was out in the desert in the USA with no proper internet connection just email - he emailed his techie friends to ask how you did some arcane vbscript stuff as we could look it up.
I worked for a few months without an internet connection, I'd go to public wifi spots and load up on all the documentation and packages I needed. I wouldn't recommend it but it definitely teaches you to be resourceful.
The first programming language I learned was BASIC, using the (quite obscure) Z-BASIC environment. I put a lot of wear on the reference manual, and had many page numbers memorized.
Google does such a good job with personalized results, that we have have forgotten how to search. Remember the old days when using a search engine effectively was a specialized skill? Search engines have gotten a lot better since then, but a lot of the improvements have been due to personalized results. It’s not easy to transition from Google to Bing or DuckDuckGo.
That being said, Google is also a good search engine, so it’s difficult to compete with them regardless of personalized results.
Using a search engine is a more specialized skill than ever.
What "Google getting better" actually means is that it is more likely to return what most people want as the first page hits. That is a tradeoff, because it obscures everything else whenever what most people want is wrong.
As a programmer, you're only going to be doing searches for things that are non-obvious, so there is a vastly higher chance of Google giving you the wrong answer than for the average search.
There is a fundamental contradiction between a search engine that tries to show you only what it thinks you want, and the fact that you don't know exactly what you want when you search, until you see some results.
I think there's something like a conservation law, that the more you make it easy to find some things on the Internet, the harder you make it to find others. Kind of like the proof that you can't compress all strings.
Bing has issues with not scraping dynamic content very well if at all. We had to eliminate libraries that render important content after page load with javascript because they'd show up on Google but not Bing.
As far as I can just about every search engine uses results from Google directly or indirectly by using a source like Bing that in turn gets some of their results from Google. If you won't call something a search engine unless it doesn't use anyone else's search results you might have a hard time naming more than one. You can't escape Google.
And from what I've seen, those who don't google consistently also fail to understand the answers they find when they do google things. It is, in fact, an essential skill.