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 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 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, you can use console.log to get the job done.
Nearly every programming language 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 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 originally appeared on the Firehose blog, where I write stories about, learning to code, career advice, and making it happen.
Top comments (26)
Or set security guards on the doors to stop the crime taking place. Use Design By Contract, and place preconditions at the start of methods and postconditions at the end. They will catch 95% of your bugs.
In addition to the tips above my contributions are:
Almost all programming environments support a real-time debugger, allowing you to step through every line of code in your application while monitoring the state. Way too few programmers know these tools exist, know how to use them, and then use them to find out what your program is actually doing and where it actually fails.
Debugging actually takes a long time. There is a famous quote.
"The most effective debugging tool is still careful thought, coupled with judiciously placed print statements." - Brian W. Kernighan
I find that more to the point.
Kernighan said that in 1979. I don't know if you've noticed, but software and tools have evolved a little bit since then.
It should not. However, I do see there are languages and environments, where setting up a debugger may be hard.
But most people are application developers and don't do embedded etc. Those folks should really only use a debugger if possible (yeah, parallel programming indeed is a prob here) because usually it's even faster than printing, gives a lot more info, you can usually change stuff in the process and you don't forget print statements which may find their way into a public release.
I am working mostly with .NET Core and starting to debug is a matter of pressing one single keyboard key. Writing a debug print statement is actually more effort to me.
"Famous quote" doesn't mean it's right. I know a lot of famous bullshit quotes.
And yes, of course you need a working brain to do effective debugging, but a debugger sure helps a lot. Especially when your application requires recompilation to add your print statements just hooking in the debugger and seeing what's going on is often a LOT faster.
I don't agree. I'm actually so much lazy I rarely use the debugger. That gives me a whole lot more time to work on other things instead. If you spend too much time on it you are not productive. You are just messing about.
And one more thing. This is not a
bullshit quotefrom the author of C as he definitely knows more about programming wisdom than anybody here combined.I really don't know what you do when you mess about with debuggers, I use the debugger to find out what's wrong with my application instead of messing about with print and guessing, fix the issue, and move on
Good job, you almost made a good argument there: yourlogicalfallacyis.com/appeal-to...
That's the fallacy there. I don't appeal. I respect. Which you don't. No one really likes a wannabe smartass. Plus I have much experience in Software Development to think of my own and to have a pragmatic view of things that work and things that not. I suggest you try that in your life and maybe you will get more free time and less time to be cocky.
Your whole comment is a big "lol". Thanks for the boring conversation, I'm done wasting my time on you.
Thank you for verifying my assumptions to the world. Go on debug something now.
He made a mistake with citation. Other than that mistake he was not the one who was rude. He didn't claim that the other guy was offering 'bullshit' and he didn't resort to being rude until Janne was a douche about it. Janne is the dickhead in this situation. Not Theofanis for making a mistake on who said something.
Edit: Just realised how old this is! Apologies for piping up but my point still stands in my opinion so I'ma leave it thurrr
Again, whoever made the statement is irrelevant. Appeal to authority is a shit argument as well. Rudeness also matters exactly none at all to the correctness of the statement.
Well it does hold relevance when that was the turning point of this particular conversation turning sour. I didn't say anything about appealing to authority. Your last statement was the only thing you said that is true. You can be correct and not a cunt simultaneously though.
Sure seems to me that you are the cunt and dickhead in this conversation if that's all you've come here to do, to fling random insults without making a point.
I did make a point. You can be correct without being a cunt. Something you clearly struggle with.
Thanks Duke! To me, using an IDE was a personal preference, till I started working on projects which deal with large scale code. I cannot emphasize this more, that using an IDE has a lot of advantage over a pure editor. Simply stated, makes life easier for developers and saves them from many pitfalls, and improves overall productivity.
This. I can't live without my debugger!
When I was in college, a prof once said, there is no engineer that knows everything, that never needs to consult a reference. Good engineers keep their references close at hand, and know when to consult them.
he then went on to detail a bunch of desk refs which are not salient to this article.
This was of course before Google was a thing. But I think the sentiment applies. A good engineer knows when to stop bashing their brains out on the keyboard and just look it up.
My Uncle once said, if it's built by people, people can fix it. Which is a deceptively simple sounding idea. But when you crack it open and start applying it is a gamechanger.
LONG LIVE console.log()
Does someone know the first who face a given problem?
I mean, the moment when you google something and "No records found".
It's SO rare to run into an originally new problem. 99.999% of the times it's probably a different manifestation of a problem somebody has faced before, so you just need to rethink and rephrase to get answers.
this is not always true. based on the tool you use (could be the language, framework or anything else) you could get face some wired situations no one else ever faced before.
last semester our parallel programming prof asked us to do the homework with multi-pascal and apparently it's community dose not exist (and he knew it). so, we had to figure out what to do without any help.
God it was hard
👍🏽
Some comments may only be visible to logged-in visitors. Sign in to view all comments.