DEV Community

Cover image for Here's What You Can Learn In 10 Minutes That Will Be Useful For The Rest Of Your Programming Career
Ken Mazaika
Ken Mazaika

Posted on

Here's What You Can Learn In 10 Minutes That Will Be Useful For The Rest Of Your Programming Career

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)

Collapse
 
kaitainjones profile image
Kaitain Jones

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.

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.

Collapse
 
erebos-manannan profile image
Erebos Manannán

In addition to the tips above my contributions are:

  • Use an IDE, it will often understand the problem much before you and help you with everything you need to do as a programmer.
  • Learn to use a debugger. Forget console.log, forget puts, forget echo, fire up that debugger and see exactly what is going on.

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.

Collapse
 
theodesp profile image
Theofanis Despoudis

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.

Collapse
 
vinaypai profile image
Vinay Pai

Kernighan said that in 1979. I don't know if you've noticed, but software and tools have evolved a little bit since then.

Collapse
 
structed profile image
Johannes Ebner ☁🎮 • Edited

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.

Collapse
 
erebos-manannan profile image
Comment marked as low quality/non-constructive by the community. View Code of Conduct
Erebos Manannán

"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.

Thread Thread
 
theodesp profile image
Comment marked as low quality/non-constructive by the community. View Code of Conduct
Theofanis Despoudis

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 quote from the author of C as he definitely knows more about programming wisdom than anybody here combined.

Thread Thread
 
erebos-manannan profile image
Comment marked as low quality/non-constructive by the community. View Code of Conduct
Erebos Manannán

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...

Thread Thread
 
theodesp profile image
Comment marked as low quality/non-constructive by the community. View Code of Conduct
Theofanis Despoudis

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.

Thread Thread
 
erebos-manannan profile image
Comment marked as low quality/non-constructive by the community. View Code of Conduct
Erebos Manannán

Your whole comment is a big "lol". Thanks for the boring conversation, I'm done wasting my time on you.

Thread Thread
 
theodesp profile image
Comment marked as low quality/non-constructive by the community. View Code of Conduct
Theofanis Despoudis • Edited

Thank you for verifying my assumptions to the world. Go on debug something now.

Thread Thread
 
Sloan, the sloth mascot
Comment deleted
 
adamthewizard profile image
Comment marked as low quality/non-constructive by the community. View Code of Conduct
Adam • Edited

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

Thread Thread
 
erebos-manannan profile image
Comment marked as low quality/non-constructive by the community. View Code of Conduct
Erebos Manannán • Edited

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.

Thread Thread
 
adamthewizard profile image
Comment marked as low quality/non-constructive by the community. View Code of Conduct
Adam

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.

Thread Thread
 
erebos-manannan profile image
Comment marked as low quality/non-constructive by the community. View Code of Conduct
Erebos Manannán

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.

Thread Thread
 
adamthewizard profile image
Comment marked as low quality/non-constructive by the community. View Code of Conduct
Adam

I did make a point. You can be correct without being a cunt. Something you clearly struggle with.

Collapse
 
engineercoding profile image
Wesley Ameling

I really have to agree on both points, however I have the opinion that one should not throw print functions entirely out of the window. The print function can be extremely useful when for instance one is debugging a multi threaded program. It can reveal the sequence of actions that happened, and the programmer can respond accordingly to that.

A debugger in the above case can sometimes miss this sequence, and one definitely misses the overview of this sequence with a debugger.

In my opinion, this is a "pick the right tool for the job" case. A debugger is extremely helpful, but is not everything.

Collapse
 
mathur_anurag profile image
Anurag Mathur 

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.

Collapse
 
thetuftii profile image
Claire Pollard

This. I can't live without my debugger!

Collapse
 
nsvoid profile image
(Null Static Void)

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.

Collapse
 
mauriciob91 profile image
Mauricio Berlanga

LONG LIVE console.log()

Collapse
 
fortegabbm profile image
ferOrtega

Does someone know the first who face a given problem?
I mean, the moment when you google something and "No records found".

Collapse
 
ighallas profile image
ghallas

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.

Collapse
 
javidizadfar profile image
Javid Izadfar

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

Collapse
 
jenniferlynparsons profile image
Jennifer Lyn Parsons

👍🏽

Some comments may only be visible to logged-in visitors. Sign in to view all comments.