Here's What You Can Learn In 10 Minutes That Will Be Useful For The Rest Of Your Programming Career
Published: 2017-03-01 21:26:23

---
title: Here's What You Can Learn In 10 Minutes That Will Be Useful For The Rest Of Your Programming Career
published: true
description: There is one remarkably simple trick you can learn in only a few minutes that will be useful for the rest of your future as a programmer. And there's a critical reason why this one small trick is so significant that is important to understand
cover_image: http://i.imgur.com/U4C2LsZ.jpg
tags: 
---

There is one remarkably simple trick you can learn in only a few minutes that will be useful for the rest of your future as a programmer. And there's a critical reason why this one small trick is so significant that is important to understand

## The 10 Tab Rule

In programming, you're going to run into problems, error messages, and situations in which your program isn't doing what you think it should. How you react to these scenarios will be the difference between being an okay programmer and an amazing one.

The “10 Tab Rule” is a simple process that can solve almost every problem you'll encounter as a programmer. What's the rule?

### When problems arise, do these 3 things:

* Articulate the problem in a well-thought-out search query
* Search it using Google (or another popular search engine)
* Open each of the top 10 results in new tabs. Read or skim each of the tabs, then return to your code.

This simple routine– which will take roughly 10 to 15 minutes– will help you solve almost all of your problems as a developer. The difference between experienced and [inexperienced developers](https://studywebdevelopment.com/programming-languages-for-beginners.html) is this: experienced developers immediately acknowledge what they don't know and set out to find the answers, while inexperienced developers often times don't have the knowledge nor the humility to begin looking for answers.

It's a subtle mentality switch, but it's important. Beginners often have the mentality of:

> “I don't know, and I feel stupid because of it.”

However, experienced developers have an entirely different mentality…

> “I don't know, let's figure this out as quickly as possible.”

And it turns out, with Google, nearly all of the questions you could have about anything are at the touch of your fingertips.

Turning to Google sounds easy in theory, but it's pretty unlikely that going to Google's homepage will answer your question. Instead, a huge part of being a good developer is coming up with a reasonably effective twenty- to fifty-character description of your problem.

20–50 letters isn't a lot of room to communicate the problem. And searches like, “my app doesn't work anymore” might be 26 letters, but won't lead you any closer to a meaningful solution to your problem.

## Before you are able to use the internet to solve your problems, you need to fully understand the problem first.

The most important skill that software developers [cultivate over time](http://learntocodewith.me/posts/ten-thousand-hours/) is the ability to solve problems using two specific steps:

* First, fully understanding the problem with your code.
* Second, looking for the solution to the problem based on your understanding.

It's far too common to look for the solution to a problem before you fully understand it, and doing so will likely be a frustrating process. If you encounter an error message you've never seen before, a quick search for the text of the message can give you a lot of the context around the problem.

## When writing complex algorithms and business logic, there is one specific problem that will account for nearly every single error message you'll see.

And this problem plagues both those starting out and people who have been programming for decades.

***It is incredibly common to think your computer program is doing one thing when it's actually doing something else.***

It's your job as a programmer to make no assumptions about what your program is doing, and use all the tools available to you to verify that each of the many assumptions you have about how your program is working is true.

* Thinking that a variable is set to one thing when it's actually something else is very common.
* Thinking a certain method returns a certain value when it actually returns a different one is common, too.
* Thinking a function does one thing when it does something different altogether is another common one.

*They're all variations of the same problem: thinking your code works one way when it works in a different way.*

When this happens, it is your job to put on your detective hat and determine exactly which line of code is doing the wrong thing.

In ruby, you can use tools like puts, bye_bug, or pry.

In [JavaScript](http://blog.thefirehoseproject.com/posts/nodejs-vs-rails/?utm_source=devto&utm_medium=site&utm_campaign=unpaid&utm_content=10_minutes), you can use console.log to get the job done.

Nearly every [programming language](http://stories.thefirehoseproject.com/coders-compass/7-most-in-demand-programming-languages?utm_source=devto&utm_medium=site&utm_campaign=unpaid&utm_content=10_minutes) has tools built into it to allow you to figure out which line of code isn't behaving the way you think it should.

## A HUGE part of [becoming a software developer](http://www.thefirehoseproject.com?utm_source=devto&utm_medium=site&utm_campaign=unpaid&utm_content=10_minutes) is understanding the tools at your disposal for understanding why you are having a problem.

Once you identify the disconnect between what you think the code is doing and what the code is actually doing, fixing the problem is usually pretty straightforward. And the ultimate solution: figuring out the line of code you don't understand, and doing effective searches to research what is actually happening in your code.

As you grow as a developer, the “10 tab rule” will become the “8 tab rule,” and eventually just turn into one or two Google searches that you need to execute to find the solutions to your problems.

But the important lesson to take away is that understanding the problem is usually the hard part.

*Once you understand the part of your program that isn't doing what you think it is, finding the solution becomes pretty easy.*

## Thanks for reading this post! If you liked it, I'd appreciate it if you shared this post on Facebook or Twitter!

FYI: [This post](http://blog.thefirehoseproject.com/posts/10-minutes-learn-programming/) originally appeared on the [Firehose blog](http://ift.tt/1L2P6yH), where I write stories about, learning to code, career advice, and making it happen.