Introduction

The internet is a tremendous source for learning skills. The information available to us as coders is vast. However, after you learn the syntax and basic theory behind programming, there is a tendency to struggle with the veritable firehouse of information out there. StackOverflow is a testament to this, but really only the beginning. For every question you have, you will find quite literally thousands of potential answers. You will find yourself in some pretty specific forums at times as a developer.

Only sometimes...

How do you know if some rando on the internet is right? Maybe they’re kinda right? Maybe they’re absolutely full of shit? In this brief post I will be going over several very subtle yet vital and generic tips for sifting through all of the noise.

Intended Audience

This is almost entirely for new coders, however, anyone continually finding themselves taking bad advice.

Tips for Filtering the Internet

When to Query

No one wants to be a copy pasta coder. No one wants work with a copy pasta coder. Don’t be a copy pasta coder. That being said; while relying on Google or StackOverflow too heavily is an impediment, Refusing to use these tools is absurd. Again I am going to preach balance here. Here is my rough order of operations when determining how I’m going to solve a problem;

  1. Coding from memory - This should always be your goal. This demonstrates mastery and means you are in that “flow state” people talk about. It’s worth noting that I do not do this much anymore as I am very much a generalist at this point in my career.
  2. looking at my own code - Often times I will recall that I solved a problem in a previous bit of code! I will take a peak and use it as an example to draw from. I do not copy pasta from my own code, this usually means you need to refactor your code to be more DRY.
  3. RTFM - At this point, if you cannot solve this from memory and you have no code to draw from… It’s time to read the manual! Sometimes the manual is fucking garbage. What then?

  4. Read the source code - There is a lot of worthy or at least inspiring code out there with utterly trash documentation. Sometimes they are amateur projects, sometimes the documentation is just not organized well. Never hesitate to step into the source code. The best way to do this is with a debugger like pdb. I’ve caught many a bug in upstream dependencies this way.

    You may also try looking directly at the source. Looking at something like the json decoder you will not only learn the intimate details of the thing you’re trying to wield, you will probably learn some good habits.

  5. Now we query - When I’m all out of ideas its time to tap into the googles. I can use the previous information gathered in formatting my queries.

How to Format Your Queries

Using any relevant information gathered I start immediately narrowing my searches;

  • Ensure version matches - I’ve wasted soooo many hours reading the wrong version of documentation or trying to implement a feature that is either deprecated or not in my codebase yet.
  • Ensure relative dates - An example here is that you can automatically disregard any JavaScript advice pre 2015. Unless you’re maintaining some legacy internal webapp on ie6… then you only look at the old stuff! It’s all about context here.

Exceptions to These Guidelines

There are a lot of things to do before turning to the internet. My level of proficiency in the task at hand will greatly dictate how this all plays out. These are more guidelines and should never be adhered to strictly. You’ll find your own exceptions, but here are some of mine;

  • If I know nothing of a subject matter, I begin with the query phase.
  • If I’ve never solved a problem I start by browsing the manual. e.g. when I was wielding mailgun to build a jekyll form I was living in the mailgun manual.
  • Any exceptions my code throws I am immediately stepping through the code.
  • If you are coding on the cutting edge… all bets are off. I’ve done some desperate shit in the early days of CSS/JS.
  • If I see an error thrown that I know I’ve solved often but can’t put my finger on it I will actually skip straight to pasting it into the googles.

Quite frankly it’d be foolish to not use the largest database of human knowledge as an extension of your own knowledge. I code in 5+ languages in a given year, all with their own libraries, frameworks, plugins and codebases. This would not really be practical for a normal person without relying heavily on googling, “combine strings in python”. I combine strings in ruby, jinja templates, python, javascript there is no way I will remember these things.

Critically Evaluate Your Sources

Always be careful of what you read. If you’re reading the blog of the guy who wrote your framework, you can probably trust him! Some random on StackOverflow… It depends. I have over 20k rep on StackOverflow and most of my answers were garbage. I asked a lot of questions as an early adopter.

Ask yourself;

  • Is this thread or question solving the exact issue I am?
  • Do they source their answers?
  • Is there any push-back or critiques in the comments?
  • Do I have any critiques or questions?

Conclusion

Context. Context. Context. Knowing when to even bother consulting the internet is important. Try to embrace it in the right situations. You dont need to remember the entire DOM api but if you parse URLs often you would be wise to memorise common url methods. So be intentional with what you memorize and what you reference. The most important thing is to be very critical of non canonical sources (StackOverflow, forums, etc).

Next Week

I’ll be demonstrating the flexibility of django by extending and combing two django applications to achieve the specific features that I want. Django Photologue does not have video support (encode/thumbnail/resize), so we will be extending the Gallery Model with some fields of our own!