I got a 33 on the science portion of the ACT.

This was my best score of the four sections.

I’m not saying that to brag, I’m sure tons of you got a higher score than me, but I was able to get that score with virtually no preparation, and I certainly wasn't a master of science. In fact, throughout high school, science classes were consistently some of my lowest grades (I’m talking C’s and D’s, not 98’s instead of 100’s.)

So why was I able to do so well?

As much as I’d like to believe I’m some sort of genius, the truth is, the science portion of the ACT just isn’t that hard. Seriously. Most of the answers are directly in the questions.

So why is it the most dreaded portion of the ACT? Why do so many people consider it the hardest section?

They let themselves get caught up in the details.

They see some obscure number like 380 μatm and think to themselves “what the f#@! does that mean?”

But heres the thing, the question isn't asking them what it means. The question's simply asking them to find that same number on a chart somewhere and pull the answer from there.

People who do well on the science portion of the ACT don’t do so because they’re geniuses or because they’re experts of science, they do so because they're good at abstraction.

They can look at a problem, figure out exactly what information they need in order to solve it, and ignore everything else.

And this my friend, is the secret to becoming a successful programmer... abstract thinking.

What is Abstract Thinking

I’ve heard it said that about one-third of CS students drop out in the first year, and I truly believe the difference between them and the ones who move on isn’t some sort of god-given talent that only the elite are blessed with, but simply a lack of abstract thinking.

Here’s an example of it in practice.

Pretend you’ve never worked with OAuth before, and one day at work, you ask a colleague to explain it to you. They then give you an explanation that goes something like this:

“OAuth is an open-standard authorization protocol whereby you let a third party provider like Google or Facebook handle authentication for you by providing a client id and a client secret for security purposes, and then redirecting users to a particular url defined by the provider where they will be asked to consent to the request, after which the provider will redirect the user back to a callback url on your site along with a JSON object storing a predefined set of information related to that particular user.”

At this point, most people have one of two types of response.

The first sounds something like this:

“Yeah I lost you at open-standard authorization protocol.”

This is an example of non-abstract thinking.

You're allowing the minutia to distract you from the heart of what’s actually being said.

The second response is a bit more interesting, and might sound something like this:

“Ok yeah I kind of get it. So basically you just set up some sort of credentials to prove you’re not doing anything sketchy, then, when the time comes, you send a user over to Facebook or Google, where they do some sort of setup and send the user back to your site with some information about them. Cool.”

That’s abstract thinking.

You abstract out all of the technical jargon like “authorization protocol” and “client secret” and try to understand the essence of what’s actually going on.

Now I’m not saying that the technical stuff isn’t important. You’ll definitely need to learn what a client secret is at some point if you want to implement OAuth, but that can wait. First you need to understand the big picture. Everything else makes a lot more sense once you do.

So how can you become an abstract thinker?

The best way I’ve found to force myself into abstract thinking when I come across something that doesn’t totally make sense to me, is to ask myself three simple questions:

1. What does it do?
2. Why does it do it?
3. How can I use it?

Let’s take a closer look at how you should aim to answer each of these questions.

What does it do?

Try to be as confident as possible. Don’t guess. Even if you’re wrong, this provides you with reference point through which you can judge your wrongness and determine exactly how wrong you were and what specifically you were wrong about.

Why does it do it?

What problem does it solve? Why did the original programmer even bother developing this in the first place? I’ve found that if I can figure out why a certain technology (or method, module, framework or library) exists, it really helps solidify exactly what it does.

How can I use it?

Now that you have general idea of the why and the what, the next step is actually figuring out how to use it. At this point, you should try to ignore any more questions you have about the why and the what and just focus on building something that works. You can always come back to those questions later on if you need to, all though often times the answers become clear after writing a little bit of code.

Once you’ve answered those three questions, the next step is simple:

Practice It.

Nothing will help you understand something in the world of programming better than rolling up your sleeves, getting your hands a little dirty, and doing the work.

Nothing.

If you’re looking for a maintainable way to force yourself to put something into practice on a consistent basis, I actually wrote a separate article about a technique I use for that.