Stop Googling

"Beyond the fact that you will most likely find exactly the answer you are looking for, there are some other side effects."<p>That's either naive, or only looking at simple libraries, or has the luxury of taking as much time as necessary to dig/poke around, absorbing multiple author styles. My head starts to hurt after looking at often un- or poorly-documented libraries written in a mishmash of styles.<p>I often search first - google/irc/bing/mailinglists, etc - because I'll find out pretty quickly if other people are really <i>using</i> the library. They'll have found and dealt with the real world issues that come up (the docs say X, but <i>really</i>, you should do Y, because of performance, security, etc). If <i>no one</i> is using something, perhaps there's a reason - searching will turn that up.<p>Finding an error message like "Foobar is barfoo-ed on line X", then having to trace through back from line X through 30 calls, then finding that all I see is a sprintf() error message of "%s is %s" doesn't really help. Yay - I read the code! It's not useful/helpful in debugging my <i>real world</i> use of your library, not the few aspects you felt like documenting or commenting.<p>Looking at code and docs alone only solves my issues about 25% of the time - maybe up to 50% depending on the platform/problem domain. I guess all is magical in the Ruby/Rails world - <i>100%</i> of all problems are solvable solely by looking at the purity that is all Ruby code, apparently.

I'm sure I'll be in the minority here, but a huge benefit of using libraries is that I don't have to know how they work, or care. The documentation says 'call foo() with this argument to do bar', and that's all I want to care about. I have other things to worry about (like my own code), than to want to dig into the internals of somebody's else's library to figure out something which should be easily documented.

I didn't start programming until Google was in full swing - what I'd like to know is how much Google search 'changed the game' for learning programming languages. If you know the basic principles of programming then you can always just search for 'how do I _____ in ______' and get your answer quickly. Before the Google age, I suppose you'd have to read documentation much more thoroughly and build up fluency in order to get anything done. <i>Has</i> Google search and other web resources changed daily programming drastically?

Sorry, but if the library doesn't provide documentation as to the functionality it provides that can be indexed by Google, I'm not using it. I don't have time to go through code-bases with differing organizations, styles, and sometimes multiple languages and layers just to find out if it has feature x and how to configure it.<p>I agree with the side-benefits of reading code, but accessing the strength of the library is more efficiently done by its documentation and community and not directly by source.

Perhaps I'm old school, but I view undocumented functionality as something that may not always be there or behave the same in future releases. While I <i>can</i> deal with that since it's open source, it doesn't mean I want to. Libraries with good documentation are frequently much safer bets, and I've found good documentation is a great indicator of the maturity and stability of the project.<p>Example: How many people would use Linux without the man pages?

There is a cultural reason for googling instead of looking at the source: a lot of developers started programming for closed platforms like Windows or Mac OS, where looking at the source was not an option. In the same way, if you are accustomed to heavy frameworks like the ones released by Microsoft / Sun / Oracle, you don't seriously consider writing your own instead of waiting for their next latest-and-greatest tech release that is supposed to solve all your problems.

Wouldn't this be better titled "Start Looking At Code" instead of "Stop Googling"?

Ah, that's a pet peeve of mine... I've always loved looking at the guts of any library I use, first because I often learn something new, second, because otherwise how can I rely on it?<p>But, a lot of programmers I know, don't look at the code for some reason, they just search and search on google, then go to irc to ask around and waste a lot of time when they could have found their answer in 5 minutes...

Personally, there are very few experiences I find more miserable than looking at other people's code. I'm sure other people feel the same way about my code. If I were in this position, I would probably start by looking at the documentation. If the feature I needed was in the code, but not in the documentation, I wouldn't want to use it.

Another aspect: People who don't dig into their libraries are much less likely to submit patches fixing minor issues they find. Quick digging through the source tells me a lot about a library - whether or not it can do something, if it's a horrible mess and should not be trusted in the first place, etc.<p>"Less google! More grep!"

Google used to be "the search engine for smart people". Now, as it is the de facto standard, it is "the search engine for everyone".<p>That means when I search a part number it turns up a pop cd by serial number, when I ask for information on a scientific subject I get a 6 year old yahoo answers post, etc.<p>I realize now that, in the past, the most value I extracted from Google was finding good resources to refer to again in the future.<p>I've been considering writing a tool that, upon being queried, figures out 6-12 of the best resources available and googles within them for that query. Kind of the "Yahoo of Google" (back when yahoo was a directory based system)

Better advice is, "if Google doesn't find it, don't stop there".

I completely agree with this article. I'm amazed at the self helpless of some programmers. I see people going to great lengths to try to find problems when there's a more direct route available.<p>They will threat anything not written by them as a blackbox and if it's not working they will poke around it endlessly, they will do anything but walk through the code and find the root issue.

Speaks a lot about the Ruby community that the answer here is not "rtfm". Typically there ISN'T a 'fm' to be found, and who knows how the code's getting monkeypatched, even by the library itself. So no, I don't trust that because I read the subset of code re: the thing that I care about that I fully understand the ramifications. I'm also guessing that the OP gets paid by the hour.

Guilty as charged. As a self-taught code tinkerer, Googling has become a major crutch, and I've found time and time again that Google just doesn't have basic answers that learning how to quickly scan the actual code can provide.<p>"Here is hoping this article lights some peeps on fire instead of lighting a fire for them."<p>Definitely a good fire to start.

I do not think any of us are born with the ability to understand the structure of GitHub and Rails projects. These are learned abilities.<p>How do we learn them? Two ways. (1) spend time on our own. This can either be brute force (i.e. just exploring every folder over several projects until a pattern emerges) or though a guided tutorial. (2) Ask someone with more experience.<p>As for as (2) goes, when someone asks me a question that I think is trivial, I try to realize that its not trivial to them. This person is asking because they respect my ideas and they think I can save them a good deal of time.<p>I don't hold everyone's hand though. Sometimes I do respond with "consider searching for X and trying Y on your own". Where the appropriate line lies for direct answers versus gentle encouragement, I do not know. However, politeness, in both cases, is free.

This is what I like about <a href="http://railsapi.com" rel="nofollow">http://railsapi.com</a> (which is just Sdoc), it gives you searchable ruby docs, and each method comes with a link to the code on Github.<p>This way when you're looking at, say, the Request objects :remote_ip method, one click gets you to the implementation along with the ability to follow the code around the Class.<p>And since the code for it's available as a standalone (<a href="http://github.com/voloko/sdoc/" rel="nofollow">http://github.com/voloko/sdoc/</a>), your not limited to just the Rails docs, but any ruby code on Github.

The correct title is<p>"Don't stop when googling turns up nothing"<p>Googling for info is near optimal, it should not be abandoned. Sadly, I can get an answer from google quicker than I can from coworker.

So, in summary:<p>"So how would I have approached my dudes problem? [8 step list follows]<p>How his friend tried to solve the provlem? [1 step list]<p>Following this line of thought to its logical conclusion, if everyone thought thing was such a bad thing, Hacker News would likely not even exist. Sharing knowledge is what the internet does best.<p>(Disclaimer: I'm not advocating never reading source code, I do it all the time for topics I truly want/need a deeper level of understanding on, but for the rest of the time…)

"... you will quickly get a feeling for how the project is organized (or not organized). This helps determine if you really still want to use this project."<p>I was looking for a simple Python webserver on which to do some Comet stuff a few months ago, and despite some fairly limited documentation, reading the code made it obvious how to use Tornado and that it was a straightforward, well-architected solution to the problem I had. Whereas Twisted was a disaster that I did not want to get anywhere near.

Funny, I do the same exact thing with John's MongoMapper codebase!<p>(Not trolling, there is an acknowledged lack of documentation for MongoMapper; I'm just poking fun at John)

No matter how much you agree with the author's opinion, Googling has the strong benefit of being a fast sufficiency condition. If you see a google result about your feature, you can be 99% sure the feature exists.<p>(Unless it's a feature request, I suppose)<p>The only thing to keep in note is that google isn't a necessary condition. Not seeing a google result means you might want to try investigating further, not that you want to get yelled at by this dude.

It's strange -- I have never used Google for programming questions. When I was learning, Google didn't exist; I had to read a book or figure it out myself. Now, Google never has the answer to my question, so I'm again forced to figure it out myself.<p>The answer to specific programming questions always lies in the code. If everyone looked at the code first, our software would be 100x better than it is now. (More eyes, more shared experience.)

From my experience, reading code is a super important skill that just isn't taught in colleges. Just as reading and writing English (Or any other language) are separate but related skills, so too reading and writing code are separate but related skills. If you have a hard time reading other people's code, go practice. Learning to read code was one of the more enlightening experiences I've had as a programmer.

The problem I've seen with some junior developers is not that they run to Google it's that they aren't very proficient at using it. On a number of occasions in the last couple of months I've had a junior dev stuck on a problem for hours. On each occasion I sat down with them and once I understood the problem went and did my own googling and cam up with the answer in five minutes.

To people who are arguing that you can't look at the code because it's poorly documented or not readable:<p>that's probably a sign that you don't want to use that code especially if YOU can't understand what the hell it's doing.<p>I tend to look at tests first more often then dive into the actual code.

It seems to me the worse problem is those who come across a problem like this and just assume it will not work without searching for the solution OR looking at the code. It should be obvious to any developer that both methods of solving your problem are useful.

Why wouldn't you just do this? - <a href="http://www.google.co.uk/search?q=site%3Agithub.com+typhoeus+redirect" rel="nofollow">http://www.google.co.uk/search?q=site%3Agithub.com+typhoeus+...</a>

Google Code Search anybody? If the answer can be gleaned from source code, you can still Google it. I use GCS often to look for examples of using a particular library or function.

You should know how to use and use all tools, incl. google, bing, ddg, github, Ctrl-F7 with searching with in text, etc. Google - is just another search tool.

You should go look at the code, and then write a blog post about it, so the next person who is googling for it can find the answer more easily....?

This guy just sounds like he needed an excuse to be an a-hole to his friend.

Why is this article about reading code and knowing what library you're getting yourself into titled "Stop Googling". The title is hardly fitting and the rant about not Googling things is just common sense and isn't worthy of a post.<p>The rest is up to the dev using the library. Use it as a black box, grey box or clear box - it's your choice and your risk.

Upvoted, just to keep you refreshing, John ;)