BROADCASTS.com

Published: July 23, 2018, 9:30 a.m.

Learning to code - or learning any new skill - is hard, but it doesn't have to be overwhelming. In this episode, Preethi discusses her tried and true strategies for learning, how to tackle challenging problems, and the methods that help her add new tools to her kit.\xa0

Written by Preethi Kasireddy: https://twitter.com/iam_preethi

Read by Abbey Rennemeyer:\xa0https://twitter.com/abbeyrenn

Original article:\xa0https://fcc.im/2uG4B0F

Learn to code for free at:\xa0https://www.freecodecamp.org

Intro music by Vangough:\xa0https://fcc.im/2APOG02

Transcript

Being an efficient learner is at least as important as being an efficient coder.

When you\u2019re a developer, your job requires you to learn every single day\u200a\u2014\u200ain spite of the constant lure of distractions like Hacker News, Twitter, Reddit, and Facebook.

You constantly encounter new code bases and new technical challenges at work. Home is no better, as you tackle open source repos and personal projects, each with their own processes and challenges to tackle.

The tech world changes fast, and it can feel like a full-time job just keeping up with the latest tools, languages and frameworks.

Long story short: learning is hard. Yet, we need to be able to learn quickly and effectively to thrive.

In the past year, I went from not knowing how to use the Chrome debugger to working as a software engineer for a leading cryptocurrency company. In the process, I rapidly learned a new skill (coding).

That said, learning didn\u2019t come easy for me.

Honestly, every new concept was a struggle. There were too many unknowns, and too much uncertainty.

\u201cHow in the world is this sustainable?\u201d I thought to myself.

\u201cIf this is what learning to code is supposed to feel like every day, I\u2019ll be miserable. Is this really my passion?\u201d

\u201cWouldn\u2019t this be easy for me if this was my passion? Do artists struggle to produce art? Do writers struggle to write a great book? Do athletes struggle to do well in a race? Are we supposed to struggle when we\u2019re pursuing our passions?\u201d

\u201cShouldn\u2019t I be finding pleasure in this?\u201d

Does it ever get easier?

Yes, it does. A year later, tackling new programming concepts is still \u201cdifficult\u201d in the sense that it requires discipline and hard work.

But it\u2019s also become an enjoyable process, rather than an overwhelming one.

What happened in the last year to make that shift possible?

Simple: I changed my perspective on learning. What once struck me as \u201cdifficult\u201d became \u201cengaging.\u201d

In the rest of the post, I\u2019ll explain how this transformation happened.

Just getting started

Learning to code is hardest at the beginning.

For example, think about the first programming language you have to learn. You want to tackle the small things like syntax and style. But first, you have to comprehend difficult core concepts like values, types, operators, control flow, functions, higher order functions, scopes, closures, recursion, and so much more.

It feels like learning to juggle\u200a\u2014\u200abut starting with eighteen pins instead of two.

When I first learned about closures, it took me many weeks to truly understand the concept. I thought I understood it when I read about it. But when I tried to identify and use closures in practice, I\u2019d find myself stumped.

That wasn\u2019t unusual. I\u2019ve observed this process as a teacher as well: new concepts don\u2019t usually click the first time around. Or the second. Or even the tenth.

But for those who stick it out long enough, there will be a \u201cbreaking point\u201d where things suddenly begin to make sense. In my example, I read literally every blog post, Stack Overflow post, and spec on the internet about closures.

Everything I read and experimented with gave me a new perspective, until eventually, I had a 360-degree mental picture of how closures worked. Closures \u201cclicked.\u201d

Getting to a point where I felt this sense of understanding of closures was super important, because it was rewarding and encouraged me to go for more\u200a\u2014\u200aincluding writing my own blog post that explained the concept.

Learning is a process, not a goal
If we see learning as something we \u201chave\u201d to do, then we rush to get it done so that we can spend the rest of our time doing something more \u201cfun\u201d\u200a\u2014\u200asomething we \u201cwant\u201d to do.

The problem is that it\u2019s impossible to know everything about anything, so viewing learning as a race leads to burnout and disappointment.

Instead, if you see learning as a process, you\u2019ll appreciate the small victories and insights along the way. This will drive you to constantly move forward.

You can compare it to exercise. Workouts hurt, and then the pain ends as soon as your workout ends. But it\u2019s never gone. It\u2019s waiting for you the next time you workout. Except each time, the pain becomes less piercing. You learn to cope with it. You become familiar with the pain, and it just becomes part of the routine. You are rewarded by better health and a better physique and are incentivized to keep going.

Exercise creates a positive feedback loop.

The same is true for learning.

Turning learning into an engaging process

Imagine building your very first web application.

At first, all you\u2019ve got is a daunting, blank text editor. The task of building the app seems almost insurmountable. You know nothing, and have so much to learn before you can make this happen.

Thankfully, you decide to go for it anyway.

From then on, your main focus becomes to do one small step at a time.

First, you create an idea. What will you build? Who\u2019s the end user? What are the constraints?

Second, you prototype or sketch out some rough designs for what you think it might look like. You ask your friends or the internet for feedback, and iterate to make it better.

Third, you research languages, tools, and frameworks that will work best with your requirements.

Step by step you discipline your mind to channel all its energy towards this one goal.

Sometimes you\u2019re writing code.

More often than not you\u2019re stalled at some bug or error.

Sometimes you\u2019re too tired to do any work, so you take a break.

Other times, you don\u2019t feel like writing code. That\u2019s okay. You spend your time researching or reading up on topics related to your project.

Eventually, after a few weeks of hard work, you\u2019ve built a foundation that can handle your big ideas. Suddenly, working on your app doesn\u2019t feel as painful. You see the reward of the initial set of hard work, and now it\u2019s just another piece of code you need to write or another bit of refactoring you need to do\u200a\u2014\u200awhich you\u2019ve done 100s of times already, no problem.

You turned what was once a daunting or dreadful activity into one that is complex and engaging.

This is how we grow. This is how we get better. Whether it\u2019s programming, dancing, running, or reading: it\u2019s not easy, and there won\u2019t ever be a time or place when you\u2019re \u201cdone\u201d learning.

Instead, enjoy the process of investing your energy into something, and enjoy the pain that comes along with it. You\u2019ll start to notice that you no longer describe it as \u201cpain\u201d\u200a\u2014\u200abecause what was once painful becomes a symbol for what\u2019s next: a sense of personal accomplishment and self-satisfaction.

In other words, struggle and enjoyment will start to mean one and the same thing. Remember the cycle:

One approach to learning technical topics

Let me tell you a little about the learning process I follow. This isn\u2019t the be-all-end-all of learning styles, so if something different works for you, please share it in the comments! In case you can\u2019t tell, I\u2019m a nerd about this stuff :)

Let\u2019s use the process of learning the React.js library as an example.

What is the motivation for learning this?
First step: I\u2019d start with a Google search for the React.js documentation and read a bit about the background and motivation for the library.

Knowing the \u201cwhy\u201d behind any topic is incredibly helpful for framing the learning process. It answers questions like:

How is this different from other solutions?

How useful is this to me?

What problems does this solution aim to solve?

Is this just a new shiny tool that\u2019ll only be useful for a few months or will it fundamentally change the way I think and code?

Reading and understanding core concepts

Second, I\u2019d read through any intro articles or examples provided in the docs.

Notice I\u2019m not touching any code yet. Reading and sinking in the core concepts comes before hands-on experimentation. It\u2019s incredibly important to do this because it lays the foundation for the rest of my learning.

Even though I might be able to get away with blindly using React.js without learning the core concepts, eventually it\u2019ll catch up to me when I run into a bug.

First time coding

After spending some time on the above steps, I start to get the gist of what\u2019s going on, or maybe even feel like I totally get it. Then it\u2019s time to jump into some code.

I typically try to build something really small with any new tool by following a video tutorial (e.g. on egghead.io) or a written tutorial before jumping into custom projects.

When you get stuck

\u2026And then, inevitably, I get stuck.

Reading the docs seemed like a piece of cake, but actually using it in practice makes me realize I have no idea what\u2019s going on.

This is when I start to feel that dreaded \u201cjust give up\u201d feeling. But instead of giving in when the going gets tough, I remind myself that pain == gain. Turning back would be cowardly.

Here\u2019s what I do instead:

I first narrow down and figure out what I\u2019m actually stuck on\u200a\u2014\u200ai.e. define the problem. Then I come up with a hypothesis for what I think could be the root cause or causes of the problem. Even if I have no idea, I just make a guess.

Then I step away from the problem and my computer and do something that relaxes me. This is incredibly hard to do when I\u2019m so upset about the problem I\u2019m stuck on, but letting go of the problem works wonders. (Ever notice how great ideas always strike in the shower?)

Now I try to debug with my hypothesis in mind. I get as far as I can on my hypothesis without looking for answers online\u200a\u2014\u200athere\u2019s something beautiful that happens when you try to solve problems by truly thinking deeply about them on your own first. Even if you\u2019re going down the wrong path, the fact that you made the effort teaches you a lot and you remember the problem space much better next time you run into it.

If my hypothesis leads to an answer, hooray! I\u2019m done. If not, I Google search for documentation, blog posts, or Stack Overflow posts that could help me get closer to the answer.

While reading, I take notes on any and all pieces of information that could potentially be helpful.

Still no solution? That\u2019s fine. I\u2019m sure I learned something valuable by reading through all that, even if it didn\u2019t directly help me solve the problem at hand. Who knows when this knowledge might come in handy next time?

At this point, if I\u2019m truly stuck, I will either post a question on Stack Overflow or ask a co-worker or developer I know.

Otherwise, I rinse and repeat until I get closer to the final solution. At some point, the answer always comes.

At times this process takes a few seconds, and other times it takes hours (or days). Either way, the process itself is incredibly beneficial to your skill set as a developer.

Getting stuck on a bug feels like stumbling in a dark tunnel looking for a ray of light. You eventually find it, but along the way you discover so much about the tunnel\u200a\u2014\u200aand it\u2019s knowledge about the \u201ctunnel\u201d that makes you strong as a coder.

Think of debugging as a chance to explore rather than a detour from your goal, and it becomes much more fun.

Rinse and repeat

By this point in the learning process, I\u2019ve built something small and tackled some small hurdles along the way. As you can see, it was a struggle\u200a\u2014\u200aclearly, I need some more practice with the new tool.

So, once again I try to build something on my own. Rather than jumping straight to a big custom project, I\u2019ll look for a repo to base my application on.

For example, if there\u2019s an online CRUD todos example (of course) using React.js, maybe I\u2019ll build a different type of CRUD application. Just different enough to keep me engaged, but not so different as to make me discouraged if something goes wrong.

Mastery

Mastery requires repetition, so I keep building more small projects until I feel like I\u2019ve got the core concepts down.

Eventually, I begin to be able to piece things together on my own without constantly referencing documentation or examples. Only then do I finally adventure out and build something from scratch on my own.

Throughout this process, I aim to make the process fun and engaging. I\u2019m constantly pushing myself to work on things that are harder than what I am capable of in the moment, but not throwing myself into the deep end so that I get discouraged and never finish.

Finally, I make sure to step away as soon as I find myself getting too frustrated to enjoy the project.

Learning is fun

With some effort and structure, learning programming turns out to be incredibly fun. At first it\u2019s incredibly complicated, and in my opinion that\u2019s why so many people get scared away\u200a\u2014\u200anot because it\u2019s \u201cboring,\u201d but because it\u2019s \u201chard.\u201d

After you go through this learning process a few times, processing new information becomes a muscle memory. You don\u2019t really think about it. You just learn to ride the pain wave and find joy in the reward.

Like magic, it becomes \u201ceasier\u201d to learn.