Amy M Haddad

Why Asking "What’s the Fastest Way to Learn to Program?” Is the Wrong Question

By: Amy M Haddad

image

Programmers have a need for speed. This seems particularly true of those who are just starting out in the field. They want to learn to program—fast.

This surprises me because programming is a skill. And building a skill of any kind takes a lot of work—and time.

Practitioners in other fields seem to recognize this. I’ve never heard a medical student say they need to learn the field of medicine fast. Nor have I heard a budding musician make the plea for speed.

Speed will come in time. Don’t make this your primary objective.

Instead of asking how fast you can learn a programming language or technology, the better question to ask is this: what are the fundamentals?

It’s Worth the Time

Say you want to have a career in programming. You want to put a portfolio of programs together as soon as possible to increase your job prospects.

In an effort to "learn fast", you may be tempted to pick up a step-by-step tutorial, for example, that walks you through the process of how to build an application. Success appears to come quick: follow the steps and build an application in no time.

Quicker? Easier? Why not?! Because it’s an illusion.

You may think that you’re off to a running start, but the fallacy of this approach is often exposed the first time you attempt to build your own web application from scratch. Or when a future program or problem falls outside of the linear model you followed. If the mental models aren’t there and the underlying concepts haven’t been learned, then working on a new, but related project is a real challenge.

The “quickly learn to program” approach can be detrimental for learning purposes. Oftentimes when programmers focus on speed, they compromise on quality which is how they “move fast.” The process becomes more about memorizing instead of understanding. They tend to settle for a surface-level comprehension of technologies and concepts.

That’s a huge sacrifice to make—especially when starting out. Instead of building a solid foundation of knowledge, it’s a shaky one.

The “fast” approach can also lead to single-dimensional thinking. If a problem or program falls within that single dimension (e.g., a particular framework or language), all is fine. But venturing outside of it can lead to that “deer in headlights” sensation because the structure isn’t there. They don’t have a solid knowledge base to rely on.

In contrast, the programmer who’s opted to master the fundamentals moves more slowly, at least initially. After all, it takes time to learn and master the fundamentals. However, speed comes soon enough.

Then, when tasked to learn a new framework on the fly, it’s a non-issue. The fundamental concepts are in place. The mental models are there to help them through the process.

Moreover, focusing on the fundamentals seems to breed both competence and confidence. The programmer has put in the time and effort to learn the how, what, why, and when of a topic or technology. They’ve built a solid foundation of knowledge. They don’t have to think about which data structure is best, for example. They know which one is.

Start the programming journey out right and build a solid foundation from the start.

Build the Trunk, Then Add the Leaves

Think of the fundamentals as the core principles of the technology or concept you’re learning about.

The fundamentals give knowledge its structure. It’s a point made clear by Elon Musk[1]:

“It is important to view knowledge as sort of a semantic tree — make sure you understand the fundamental principles, i.e. the trunk and big branches, before you get into the leaves/details or there is nothing for them to hang on to.”

When you have a solid knowledge base (the “trunk”) in place, you have prior knowledge to refer back to as you add more to it (the “leaves”).

You learn how to write a for loop, for example. But you also learn when and why you’d use one. You learn why it makes sense to use a for loop in one problem, and a while loop in another. You learn what happens on each iteration of a loop. Core ideas like these make up the “trunk.”

When the structure is in place, the details follow naturally. Nested loops, for example, don’t seem so strange. In fact, nested loops make sense because you already understand how a single for loop works. Plus, details are more meaningful when you can apply them to something. There's something to “hang onto.”

So the next time you set out to learn something new, ask yourself: “what are the fundamentals of ‘x’?” There are three reasons why this is a worthy question to answer.

Lay the Foundation

Do the names Andy Warhol or Jackson Pollock sound familiar?

We remember these artists for their groundbreaking artwork. However, they were classically trained. In other words, they learned the fundamentals of art before revolutionizing the art world.

As Pablo Picasso—another groundbreaking artist who was classically trained—put it: “Learn the rules like a pro, so you can break them like an artist.”

Picasso hints at a one of the three reasons why you ought to shift your aim from speed to the fundamentals: creativity.

Let Creativity Thrive

Mastering the fundamentals builds a foundation where creativity can thrive, according to the pedagogy of the legendary basketball coach and teacher, John Wooden.[2]

[Wooden] wanted to unburden his players from thinking about matters they could leave to automatic performance, in order to free them to think, choose, and be inventive and imaginative, and take initiative,” recalls a former player.[2]

If we master logical construct of conditionals, then we don’t have to think so deeply about using them. It’s second nature. If we master the different data structures, then we don’t have to spin our wheels debating which one is best. We know which data structure to use and why.

Mastering the fundamentals frees us to focus on creative aspects of our craft, as Wooden suggests. Now we can put our time and attention on things like refactoring, design, and readability.

Get Ready to Pivot

The second reason why the fundamentals matter is because it’s easier to pivot when learning new concepts and technologies. And in a fast-moving field like programming, learning is a given.

The fundamentals provide structure, which is why it’s easier to pivot. This is where speed comes in. Once you’ve nailed the fundamentals in one language or technology, it’s a lot quicker to pick up a related one because the core structure is already in place.

If you learn the fundamentals of one programming language—such as loops, conditionals, and data structures—it’s far easier (and often quicker) to learn another.

Writing a function in Python is different than in JavaScript. But you already know how functions work, when you’d use one, and why because you took the time and pains to really understand them when you learned Python. Now you can apply the same principles in a new context.

Build Your Programmer’s Intuition

The fundamentals approach requires a deep understanding. When you know something deeply, you inevitably feel more prepared using, thinking, and talking about it.

This level of preparation, in turn, fuels self-confidence. You’ll feel more prepared as a programmer—because you are.

As you learn something deeply, you’re also developing what I call your “programmer’s intuition.” You intuitively know what to reach for, when to reach for it and why.

You see the patterns. You connect the dots between seemingly disparate parts. Instead of guessing, you know why it makes sense to use a dictionary instead of a list. And you don’t have to think too hard about it either. The decision is intuitive.

How to Make the Shift

You can apply the fundamentals approach to programming in general, as well as specific languages, concepts, and technologies. The question is: how do you identify the fundamentals?

The answer can be fuzzy. In some cases, like programming languages, there’s a general consensus. Data structures, loops, and conditionals are considered among several core aspects of learning a programming language.

But I’ve mostly found that it’s up to me to figure out what the fundamentals are when learning programming concepts and technologies. Here’s one way to do it: get the big picture.

Start with the Big Picture

When learning something new, start with the big picture. It’s the birds-eye view of whatever you’re going to learn about.

The aim is to get a general sense of what’s being discussed and what seems to be important. When you have some context, it’s easier to step back and filter the fundamentals from the minutia.

Say you’re going to learn about classes in Python for the first time. To get the big picture, read the conclusion at the end of a chapter of a book on classes. Skim the introduction. Scan the headlines in each section throughout the chapter. Take a look at the problems or exercises.

As you do, ask yourself these questions:

  • What are some of the repeated themes?
  • What are the points of emphasis?
  • What’s a short summary of some of the main ideas?

This should be a fairly quick process, but the results can be illuminating. Answers to the questions above can help clue you into what matters most. And that’s what you ought to focus on when you take a deeper dive into the topic.

It’s not to say that the details don’t matter. They do—after you’ve got a handle on the fundamentals.

It’s easy to get lost in the details if you’re not ready for them. This slows down progress and isn’t effective for learning purposes. The details won’t have much meaning until you have something to tie them back to, as Musk implies in his tree analogy. To use Musk’s vernacular, you can think of the big picture as the “trunk” or “big branches” and the details as the “leaves.”

Identify what the fundamentals are, then focus on them. Everything takes off from there.

Endnotes:

  1. Reddit. https://www.reddit.com/r/IAmA/comments/2rgsan/i_am_elon_musk_ceocto_of_a_rocket_company_ama/cnfre0a/

  2. Nater, Swen. You Haven't Taught Until They Have Learned: John Wooden's Teaching Principles and Practices. Morgantown, Fitness Information Technology, 2006.


← back to all posts