I not only use Google frequently, I use it to search for things I myself have written in the past.
I can't count the number of times I've Googled for a programming question where the answer is found on a Stack Overflow page I've written. If it's a particularly old answer that I've completely forgotten, I've even thought to myself, "Wow this genius sounds just like me!"[1].
[1]: ... as well as "This idiot has no clue what he's talking about!"
Or a question you had years ago. Couldn't find an answer. So you did a workaround and/or forgot about it.
Now you hit the same problem search -- and find you original question. But wait! Now there are half-a-dozen other people with the same problem! So you click on all of those links.
But none of them could find an answer either. Bonus points if there's a guy who comes in condescendingly and quotes a manual or some other standard piece of information -- which is also wrong. This is usually because they didn't pay enough attention to understand the question in the first place.
I had a guy, on stackoverflow, commenting condescendingly on my question (or was it an answer, can't remember) that I was wrong and I should edit my post with his answer instead. All would be well if it wasn't on a 6 year old post at the time, and he was wrong. Ah, stackoverflow - what happened to you? It was fine and dandy when it was all loose. Now you ask a question and it's immediately flagged for various reasons. I've noticed that a lot in programming (I'm not actively programming anymore). It's always fun until the entropy of the rigidness comes in.
The one time I posted a question on SO, it got flagged as duplicate and there were links to multiple other questions that were not even remotely the same to mine. Even more so, the tagged questions were not even mutually the same!
It took two hours to carefully craft my question just to have it immediately shot down. It is needless to say I have not posted again since.
Sometimes the problem with Stack Overflow is different: the question has been asked before and there ARE valid answers... for several years ago, which are no longer correct (or the "best" answers).
I think they're over-moderating the site. It's a shame because it's MUCH better than what was before.
I'd say at least half of the questions/answers I come across are closed flagged as vague, or whatever but at the same time, were incredibly informative, useful and exactly what I was looking for.
I'll go to SO for answers, but the "culture" of the "community" nullifies by desire to participate. I want to in theory. The reality is it's not worth the friction.
I always answer my own questions if no answer was given and I found a workaround/hack to solve it. Not for myself, but chances are that in few years, if I search for the same question I'll find my own.
Extra bonus, if closed as "not a real question", heavily upvoted, at the top of the Google's 1st page of search results, and actually containing a (heavily upvoted as well) solution.
P.S. Recursive bonus: closed with a comment ("you should just google it") and now actually the top result in search output (happens quite frequently) :)
Your PS is particularly annoying when the result is from an 8 year old forum thread, and the thread was closed with "this thread is too old; use Google."
To comment on the headline, I am an experienced developer who also uses Google and DuckDuckGo several times per day. It's often faster to look up a method in the Java or Ruby stdlib that way, rather than navigating through the official docs hierarchy.
Happened to me several times to find my own answer/question on SE, or one of my work colleague's.
However, even more often I find answers that I upvoted in the past (sometimes I deliberately look for them, sometimes by accident). When I see an upvote from myself, I can be sure I can immediately use the answer because I already verified it in the past. SO is like a big, googleable, writable public wiki for me, with annotations.
It amazes me that many colleagues do not have an account, or have an account but never write or upvote anything.
In order to upvote on SO, you need both an account and enough karma on the account.
The SO people have done a great job of not requiring accounts. You can even start asking and answering questions without an account, if memory serves right.
That lots of your coworkers get by without an account is a feature of SO!
When I am struggling and things are too generic, I even use the Stack Overflow Query interface[0], if you are a SQL Server nerd you can even get the execution plan and do whatever you can dream up.
This makes me think of how fun it would be to have some sort of service that would show you your own past code and see if you'd rate it good/bad. Then you could correct what you think is bad, and it'd be fed right back into the corpus. Leveraging some kind of spaced repetition approach, it could be an interesting experiment to measure the way you grow, change, improve, and regress as a developer.
> I use it to search for things I myself have written in the past.
Heh, me too, especially on Stack Overflow. I wish they'd give us a better way to organise our answers rather than having to rely on tags or bookmarks in our browsers.
If I find a problem I can't solve I will post a question on Stack Overflow, then I go back to work trying to solve it. If I find the solution before someone else does I answer my own question on Stack Overflow.
My most updated answers have been to questions I asked in the first place.
I also get a chuckle when someone I know says they were googling a problem and found my post on Stack Overflow.
if there isn't already a word/term for this, perhaps there should be soon enough. (not an OED word, but a developer-lexicon term like "heisen bug", "smug report", "hinden bug" Like "hey i googled this problem and got auto-stacked"
I often joke that my ability to formulate good Google queries is the single most important part of my software engineering skillset. Except, you know, I'm not really joking.
Don't undercount that you also have the skill to determine whether an answer on stackoverflow (etc.) is actually correct and worthwhile.
(I taught intro to CS for the first time last year, and watched people get very hung up by subtly broken things they found on the innertubes. To the point where we simply told them not to - we'd much rather have them asking the course staff, until they've developed the experience to sort out the wheat from the chaff themselves.)
I tried to learn openGL ES from the official android tutorial, which is subtly broken all over the place. It works but shouldn't. The funny thing is that when I googled it, there were lots of complaints about it being broken, and the author responded and fixed them... but years before...
I eventually got things working, though I feel far from confident about openGL ES. Actually, embedded shader code, packed arrays, limited debugging and my rusty matrix algebra doesn't make it easy.
Google is also very good at what I call "meta-guidance." If I search for something and don't find any good results, there's two possibilities: a) I'm not asking the right question, or b) I'm trying to solve the wrong problem.
Couldn't agree more. I'm a lead web developer at a company and whenever I'm asked to interview a potential employee I give em' a short coding task. Internet access is allowed. The only restriction I give em' is not to clear their search history.
If the candidate knows the problem he/she is facing and can formulate good query to look for a solution; that's a ++
I often find that by the time I've written a clear enough explanation of the problem I'm trying to solve (in a stack overflow text edit box, usually), I figure out the answer on my own.
This right here, man. I start off going "I'm trying to do X. How do I do it?"
Then I have to exhaustively Google to make sure that it's not an obvious Google search away. Then I start listing the steps that I've tried before, and I realize a possibility that I hadn't considered before.
The possibility works, and I close the window. Oh.
These days, I usually just walk the dog. By the time that I get back, I've usually figured out the answer or figured out how I'm going to look for the answer. The dog doesn't mind that his owner is babbling about code for the entire walk because he's a dog.
Having the skills to know what question to ask is important. How, for example, would someone with 0 computing knowledge look for answers to a problem they want to solve where, say, some form of ML would be the best solution? How would they evaluate the search results?
One thing I didn't mention is that I sometimes make dozens of queries for a particular problem before I find the right formulation of words that will give me a useful result. Often those words/phrases were ones I encountered in previous unfruitful searches. In many cases finding the answer turns out to be easy, but figuring out the right question was hard!
Related is being good at debugging. There's something about having a certain intuition (in reality probably experience) on what it is that you are looking for that is critical.
I find that experience and a rigorous approach is vital for debugging efficiently. It's like being a detective, where often the most effective technique is _disproving_ your theories.
Yes. I see people getting hung up on irrelevant issues. It happens to me on occasions, but some people seems to get stuck on side effects and irrelevant errors and messages.
I find it to be very irritating if it happens for people that should know better...
The important thing to remember is that as sure you are that they're wrong, they're sure that they're right.
In general I find that asking them to explain why they think this is causing the behaviour you're seeing they can usually work out they're wrong/convince you they're right. Of course this only works if they don't scream "I've found the bug" every time you step forward.
It's valid for other things too. Over the last couple of years I find it 'easier'/'faster' to google "that thing you do when you do that in Photoshop/Illustrator/AE/Premiere/Nuke..." and I get results I want immediately. It's faster than trying to remember, fumbling around the menus and whatnots.
I was about to say that you can really only learn this by experience, but I'll bet you'd be able to learn a lot by watching someone else work and listening to them talk about their thought process out loud.
Ironically, the one time that I did not use Google frequently (as a programmer) was when I was working on Google Search. It's hard to Google the answers for how the search engine works, particularly when they're locked up in the heads of only one or two people.
Use it all the time otherwise, for personal projects and startups (really, all of my startup ideas would be complete non-starters if Google didn't exist). Just beware that if you can Google the answers, the skill is a commodity, and that the real economic gains come from knowing things that nobody else knows.
When I'm trying to do something 'big', i start with the technical papers on the subject. Often, I get those by finding the syllabus of a graduate class (or classes) in the field.
Now that I understand the big picture/state of the art, I spend more time looking for specific techniques using Google and/or Stack Overflow.
Another essential point here is when you get 'fancy' error messages. Google is amazing at finding why (and usually, The Patch) when you fail to compile random packages.
I have my own little cross-distro builder[0] and I /rarely/ bother trying to dive into autoconf/make hell before cut+pasting the exact error message into google! That very likely saved my sanity many times over :-)
Otherwise I agree with the article -- Given the number of environments and languages around, actually 'knowing' trivialities like exact library names and such is a waste of good neuron..
Much like the sort algorithm that downloads and evals Stack Overflow answers until the list is sorted, someone should make a build tool that Googles any error output, installs possible patches, and restarts the build. It could even see if adding the patch caused a new error and decide whether to roll back or keep patching.
I live in France, and I hate localized linux distributions, you can't google error messages when it's localized. I sometimes try to re-translate the message in English and google it.
Error messages are not messages for the users to diagnose anymore, they are keywords for google, give them a number. I google and if it fails, I'll try to use my brain.
there is an ironic situation: in Google Chrome, when you get an error (like a rejected certificate, or something a bit browsery), they give you a link to a completely unhelpful "help" page about the chrome browser, instead of a google search "thatsite.com <certificate rejected error>".
> “Never memorize something that you can look up.” - Albert Einstein
Here's the actual [1], and perhaps more meaningful, quote:
"[I do not] carry such information in my mind since it is readily available in books. ...The value of a college education is not the learning of many facts but the training of the mind to think."
How much you remember is also correlated to how much you actually use certain things; it can be a good signal for whether you have practical experience with X.
For some companies, it's what they need in a hire. For others it's OK to just ensure people have a sound problem solving strategy and above-average general cognition.
I think you'll find varying levels of what you might consider nitpicking depending on the sort of company you're interviewing at.
>> it can be a good signal for whether you have practical experience with X.
This should be vetted out well in advance of an interview, especially for a developer. If you don't have at least a half dozen repos somewhere with code examples of sites or apps you've built, then there's a very high chance you're not going to get an interview. I've only been coding for 7-8 years and I have an extensive GitHub page, can point to close to 200 public sites I've built (both dynamic and static) and have a portfolio full of images from other projects I've worked on.
If you can't ascertain whether a person has practical experience with a tool, software, or language then you're not doing your due diligence.
Not everyone has or needs an extensive GitHub page. I'll use myself as an example. I've got over a decade of experience working in large teams to ship commercial products. As a general rule, you won't ever see my code unless you also work for the same company. The kind of companies I work for want me for the experience from my day job. I can easily prove I worked on the projects I worked on but any company interviewing me would have nothing beyond my word for what exactly I contributed to each project. It's totally reasonable for them to ask questions that can confirm I know how to do things I claim to have done.
I mean, that's great if you build things that screenshot well, or can open source. But say you've worked on closed source network code for the last 8 years. Stuff poking around with embedded systems or fpga's aren't really clone and run, you need some hardware.
If someone is working on proprietary software most of the time and has kids to raise, they may not have focused time to spend working on projects outside of their job.
After doing a lot of interviewing, particularly when asking the same question over and over again, I've noticed the quality of what an interviewee decides to Google varies greatly and can give a lot of insight that just solving the problem alone can't. I've been amazed by some of the incomprehensible things people Google, even among those with the supposed same credentials, skillsets, and backgrounds.
Aside from whether or not they can do the actual problem, it seems to be a good proxy for skill. You can quickly distinguish between those that copy-paste their way to a solution and those that thoughtfully attempt to solve the underlying problem. Seeing what they choose to research, and sometimes having to step in and after a while and say "it seems like this is talking about X, which doesn't have much to do with this problem," speaks volumes about the candidate.
I saw a candidate, when working on a problem involving writing a simple TCP server, Google the phrase "osx port 11211". He was wondering why his tcp server was getting a connection refused message when he tried to start it. Turns out, he had copied and pasted client code from an example rather than server code.
I saw another candidate Google "socket get command line arguments" and then stare at a stack overflow answer for a few minutes that had absolutely nothing to do with the problem. What they were attempting to do was just read data from a socket. Some people just seem to throw things at the wall to see what sticks.
I didn’t realize how uniquely good Google’s programming results were until I tried Bing or DuckDuckGo and was left confused because their top results didn’t even mention some pretty significant page on a target subject.
I am however noticing a trend that I don’t like in Google results: they are trying to interpret pages more and more instead of just being a proxy. (No thanks, Google, I don’t want your attempt at a pretty summary of a Wikipedia page or StackOverflow post; the link will do nicely. Besides, it is just a little obnoxious to lift content from other sites that may prevent people from visiting those sites entirely.)
Google is not my sole search tool though. I still find it faster to search offline for a lot of things; for instance, if you have a Mac and haven’t tried something like Dash for quick access to API documentation, you are really missing a potential productivity boost. And, offline search helps a lot on airplanes.
The "interpreting", as you put it, can be really odd at times. I tend to think that in the majority of cases, it works perfectly and you do in fact get your answer without even having to click through to the site. Whether this is a Good Thing™ or a Bad Thing™ is left to each individual's discretion.
It's a little funny when the interpretation doesn't show anything useful. I've noticed this is often the case when they rip an html table out of the document and show partial rows/columns in the result set. They'll frequently display the column that contains your search term (the "key" so to speak), but exclude the column that contains the matching information you're looking for (the "value"). Other times, though less frequently, there are "answers" to your search query that just make absolutely no sense.
I've been finding Google less useful in the last little while.
It taunts me and tells me that I'm sorry Daniel, I've decided to exclude the most important keyword from your query.
Domain-specific search tools - e.g. for programming, Dash.app - have become an increased part of my workflow partially because Google simply isn't giving me the results I am looking for.
Thank you, that's a helpful tip! I used to use many modifiers for my Google queries, but Google dropped support for many of them, and doesn't seem to document comprehensively what they actually support from day to day.
I wish excluded keywords were the only frustration. Their index seems to have gotten considerably worse at dealing with any somewhat "long-tail" query. I'm not sure why.
I suspect they've won the spam battle by aggressively purging from their index, but in doing so they've lost the spam war because the false positive rate on their approach is way too high. Or maybe I'm completely off base.
My favorite modifier removal: Currently, you can use - to exclude keywords. Once upon a time, you could use + to require a keyword... until Google+ came out, and + became how you would search for people's profiles.
This. I can't believe someone approved removing the use of "+" as a search operator. It was at the very core of searching Google. It took months before I found out you needed to double-quote "every" "single" "damn" "individual" "word" to force searching by inclusion.
I think the day Google nerfed search for the sake of Plus was the day they jumped the proverbial shark. At least for me, that was when I stopped thinking Google could do no wrong. Then they nixed Reader.
Not so much inexplicably. This is common to nearly every indexing system intended to support text search. You won't see punctuation characters being indexed by most systems. Tokenization, lexeme normalization, and all that. It does make certain searches nearly impossible to perform, but the case is rare enough that the average person - even amongst developers - doesn't get stuck all that often.
Google is certainly a 100% essential tool for programming. I use it constantly, every day, and I am sure basically every single developer does the same. The most essential point in the post, imo, is that on any given project you have to wade through the details of dozens of components and tools. There's only so much room in the average brain.
I've tried to use DDG for programming but I've found that Google's efficiency is just too good to make DDG worthwhile. I guess I've decided to take the privacy hit in regards to developing activities.
you can use DDG as a default search engine, and search in google when you want by adding the "g!" flag to your query. it will kick you over to a non(less?)-tracked version of Google.
and you might find DDG is much better for devs. they have built in language guides and various other conveniences.
Right, agreed, "search engine" is what I should have said, although I suspect that even among developers Google search would be the heavy winner in terms of use.
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.
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.
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.
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.
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.
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.
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").
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.
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.
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".
Google lets you prune already-solved parts of the search space. I have a deep understanding of the technologies I work with, but that doesn't mean I remember the three lines of code that you use to slurp a file into an STL string, for example. Stuff like that isn't worth the brain space.
I guess I'm just restating the Einstein quote more verbosely, but it's absolutely true.
This small post is spot on. The search queries could have been typed by me. One of the important things a developer has to learn is how to actually use Google for software investigation. Especially with the acronyms and very short names that we use all the time, its important to know how to structure your Google queries. Writing Google queries to quickly find the correct solutions is a skill on its own.
>> Writing Google queries to quickly find the correct solutions is a skill on its own.
This is so true, and yet I haven't ever heard of anyone asking about this in an interview. It would be an interesting skill to try and assess, not sure how it would be done though.
I've been involved in interview processes where candidates were presented with a problem, given a computer and asked to solve it. Usually just by searching for an error message.
It's amazing how much productivity is killed when you have to work in an environment, such as a SCIF, where you have zero internet access nor can you use any devices that could connect to the internet. It's certainly made me more resourceful but I don't think it's something a developer should put themselves through if they don't have to.
Knowing how to search is an extremely useful skill.
I think we have gotten to the stage where an intelligent and determined individual can teach themselves pretty much anything by researching a subject on Google.
Hold key concepts in your head, Google for everything else :-)
I wonder if maybe some geniuses could parse out all of the code on Stack Overflow and connect it to some knowledge graph, connect that with Google's knowledge graph, and integrate everything into a giant programming problem solving deep learning system with Deep Mind/Tensor Flow. Or something.
It just seems like people are googling, landing on Stack Overflow, and solving the same problems so many times.. especially if you could somehow follow through from the code on the screen, the google searches, pages landed on, and then the code or commands that got entered in.. I think that a lot of these recurring questions or problems could almost be solved/programmed by an AI.
Maybe if you could get a web extension running on thousands of developers computers.. maybe for Chromebooks if it could read the code out of crosh.. then monitor all of the searches and coding/terminal commands and create a giant deep learning/reinforcement learning network thing out of that.
Or maybe for monitoring the terminal code and commands some kind of background terminal program would be needed. Maybe ttylog or screen or tailing a tty device or something.
Let's say tomorrow there was some major catastrophy in which every disk drive or tape drive was wiped, and every computer had reset. How would we fare in rebuilding society?
I guess it would be similar if in 1950, all of books lost their ink or all of scientists/engineers had amnesia. I'm not trying to make a point other than it is interesting to think about it.
Experienced programmers probably also have a good feel for whether the problem they're having is truly unique (and not worth searching for), whether others will be able to articulate the problem, and how long it might take to solve the issue from first principles, hence how much effort is worth investing in the Google excavation.
Most experienced programmers also have a good feel for how much harder it is to write a solid, tested, scalable module yourself than integrate a open source solution, even if it's not perfect.
>Most experienced programmers also have a good feel for how much harder it is to write a solid, tested, scalable module yourself than integrate a open source solution, even if it's not perfect.
Funny story, when I was just starting out in this field, my client wanted his chip to communicate with a sensor that was already on his board. This was at the time, a brand new, unreleased product. Because our hardware engineering department didn't like to communicate with the software engineering department the CPU they chose for the project didn't support i2c, but they sensor they chose (out of many thousands of different sensors from different manufacturers) only communicated over i2c.
At the time I was obviously very frustrated with the hardware engineers so I did a simple search for other sensors in the same category. Most of them would communicate over a handful of different protocols, it just so happens that the one they picked only supported i2c.
So, since I was just starting out and my client was breathing down my neck for access to the sensor that he paid for, I figured I didn't have enough time to write my own bit-bang software driver for i2c. Instead, I would just find one on google... So the driver I picked had a really tricky bug in it where it was bit-shifting the address of the device it was supposed to be communicating with. A logic analyzer came in really handy here. So my "solution" was, instead of fixing the bug properly, I just manually bit-shifted the address the opposite direction, and then the driver bit-shifted it back. At first I used the "<<" operator, right before the address went out on the wire. That didn't work, since the compiler optimizations ripped out my bit-shift command. So I manually did the shift and just put the "fixed" address in the define.
I estimate, that had hardware and software engineering communicated better, and worked together better, we could have shaved half the development time off of that project. Such a waste.
Yet all I remember is the times that third party code has failed me. It is a strange quirk of human memory.
It's not just me, either - one example was a failure in STL map that was as old as the product. It was a known defect but nobody had the heart to face it. When I showed them the defect, people got rather angry with me.
I find having a requirements.txt file really helps with this. When you struggle with a plugin and new to replace or rewrite it, removing the entry in the requirements reminds you of all the plugins you are happily using right now.
1. Google if someone had the same problem and fixed it.
2. Hope you're using OSS software and simply browse the source to find answers.
The second approach is a bit slower at first, but after you dismantled a bunch of repos it becomes natural, you get faster and the answers you find are more reliable.
Having done enough of the second approach, I find it hard to understand why people do the first -- why see what people wrote about what something does when you can just see what it does. Even man pages are some amount of here say, versus inspecting the code.
That said, I do web search some specific terms frequently to get to certain documentation that I trust, SMS search is the easiest way to get there consistently.
There's plenty of things that I can't write that I can understand. Even if I can't understand it, I can look and see what it's expecting for arguments and figure out why it doesn't like what ever thing I sent that was probably dumb.
One of the more frustrating parts of my job is dealing with junior and intermediate programmers who spin their wheels try to figure it out themselves rather than google it.
Things like spending several hours on a problem where copy/pasting the error into google yields a github issue complete with a work around or writing a boat load of code when there already exists a package or plugin that does exactly that.
The worst is when a google search would have revealed that our chosen framework already built in the desired feature they just spent the afternoon writing.
More often than not I will very deliberately type my search phrase one character at a time paying careful attention to all the autocompleted results. Very useful habit to get into as I have solved quite a few problems much faster than had I gone down the rabbit hole of my original query.
>> carefully evaluating the results and consciously separating the wheat from the chaff; they don’t blindly follow or copy-paste any solution they come across
As well as writing the correct search query, this is the other important aspect of the skill of using Google. A good programmer can look at an answer on StackOverflow and quickly determine whether or not it looks "about right" and how it can be integrated into their code.
Back before decent search engines, there was gopher or ftp search. I used to search for function names or some part of some API in gopher (or ftp search), and find source code in projects where the code was already in use. Then use that to get hints about where I was going wrong.
Google and StackOverflow fill a much wider niche however.
I'm not exactly an experienced programmer by any means, but I definitely use Google frequently. Sometimes with that 'site:stackexchange.com' or 'site:stackoverflow.com' operator added in because I know Stack Overflow usually tends to have a lot of the answers to these queries.
And then there's the CMS/framework search that might actually be more common than looking for Stack Overflow/forum/social media answers to questions. You know, where you're working with WordPress/Drupal/Joomla and can't remember what that one function or class is called that you need to use for some use case or another. Cue more Google searching, usually in conjunction with the wiki/documentation/codex/whatever it's called.
I probably Google more for questions about Netty than I do for anything else in Java. I've never seen such a useful library with such terrible documentation
I really hope people don't think this is a surprise. Before the web, Mac programmers relied on a set of HyperCard stacks from Apple to look up function calls and all kinds of obscure info. It was awesome. Every programmer I've ever known since the 1980s has always had reference materials within easy reach. That's just smart.
The only issue is the need to solve captchas because Google thinks you are scraping them.
I don't know if I am experienced or not (beyond the numbers of years programming) but I am sure "search engine oriented programming" give you a lot of advantages and connect dots that take years if you follow other routes.
When trying to find things in MSDN, it's often faster to Google it than it is to use the internal search. I can load and read a StackOverflow page before an MSDN page has even loaded.
I use Bing. Mostly for Bing Rewards, which essentially gives me a free Starbucks ~every month. But now I'm finding their search engine isn't that terrible.
I would go so far as to say anyone who brags about not using Google to look for answers (or looks down on someone who does so readily) is worse off for it. Nobody can know all the answers to every problem they will run into (this goes for any profession, not just programming) -- the first step if you don't have a quick answer yourself should be to search the internet for answers others have come up with, or at least more information.
That doesn't mean you just copy and paste whatever you find. But it means you are now more informed than you were before and can come to a better, faster solution.
I wouldn't be so sure ...In fact, Google recruits people who search for certain programming languages/terms. Pretty cool actually - a "secret invitation" suddenly appears within the search results and the candidate has to accept (and pass) a programming "challenge" to further qualify. http://thehustle.co/the-secret-google-interview-that-landed-...
I can't count the number of times I've Googled for a programming question where the answer is found on a Stack Overflow page I've written. If it's a particularly old answer that I've completely forgotten, I've even thought to myself, "Wow this genius sounds just like me!"[1].
[1]: ... as well as "This idiot has no clue what he's talking about!"