bgror

Stop Googling »

Created at: 14.10.2010 15:48, source: RailsTips - Home, tagged: rants

Yesterday, one of my inter-web buddies IM’d me and asked if I had used Typhoeus before. I said yes, so he asked me if it was possible to follow redirects using it. He said he google’d it and nothing turned up.

I sharply responded, “LOOK AT THE CODE!”. We had some banter back and forth and a few minutes later he was automatically following redirects. It seems these days that developers often think if something does not turn up in a google search, it does not exist.

The John Nunemaker Approach

So how would I have approached my dudes problem?

1. Open a browser and type in github.com.
2. Search for typhoeus.
3. Click on Paul Dix’s repo.
4. Click on lib/. lib is always where the guts of any Ruby gem are so it is a sensible first start.
5. Click on typheous/. Not the ruby file, but the directory. Most good gems just have miscellaneous top level things in the ruby file of the gem name. All the guts sit in the folder named after the gem.
6. Scanned for and clicked on the file named request.rb, which seemed like a good place to start, since we are looking to make a request.
7. Starting at line 5 there is an attr_accessor full of options, two of which stuck out to me — follow_location and max_redirects. Both of these seemed related to what he was trying to do. I also noticed right below that Paul has some inline documentation which mentions all the options, including the aforementioned ones.
8. Copied the link to the file, IM’d it to my dude and yelled again, “LOOK AT THE CODE!”

If you do not know me, you may think I was a bit harsh breaking out the all caps, but it was all in good fun. The point, however, is not in good fun. It is deathly serious. As developers, we write code. If you can write code, you should also be able to read code.

The Side Effects

Beyond the fact that you will most likely find exactly the answer you are looking for, there are some other side effects.

First, as you look through the code, attempting to find your answer, 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. If it looks like a mess, do not trust it. Find something else, or GASP, create your own project that does what you need. Repeating others is good.

Second, over time you will soak in more and more different coding styles and techniques. This will help you in your continuing efforts to get better as you are no longer in a box only looking at your own code. Several other people have expounded on the benefits of code reading so I will not dive in deep on that topic here, but suffice to say, it is really valuable.

Third, you will learn more about how the project works and may discover there is a better way to do what you are attempting. Some hidden option that no one has blogged about or utility class with handy helper methods.

Fourth, you will get faster and faster at tracking down where code is that you need. You will learn quickly how to find project’s code and where to find the code you need in the project. The steps above that describe my approach typically take me about the same amount of time as it would to search on google.

Fifth, and finally, and maybe most importantly, you will become addicted to reading code. You will start to shiver and shake when you have not had your fix in a few days. You mind will begin to race with ideas. You will see how someone else solved a problem and think of better ways.

You will create. You will improve.

Conclusion

Ensure that GitHub is always near your fingertips. Install gemedit or a similar utility. Next time you go to google for an answer, stop, break open the code and learn. Here is hoping this article lights some peeps on fire instead of lighting a fire for them.