Two months ago, I started learning how to code. I’ve approached coding three times in the past seven years and always quit. This time, I decided to figure out how to learn first and gave myself a word to not stop until I can make a simple web app myself.

Last week, I finished my first useful React app and decided to reflect on what I’ve learned in the past two months. I’ve seen many articles describing tips and tricks for studying coding, but very few cover the process of learning and the psychology behind it.

In summary, you need to build a habit of learning, find what you’re obsessed with, and crawl your way through The Suck. I also explain how drawing and spatial cognition help improve understanding, how you can enhance transfer by creating more hooks for recall, and how to design an environment for concentration instead of pushing yourself to focus.

P.s. If you aren’t learning to code, you’ll benefit from reading the habit part as well – the principles behind it apply to any routine.

P.p.s. If you haven’t seen my work on learning, I’d recommend reading both posts so that you form a complete picture of how to learn:

How to remember what you learn

Make it time-based, apply metacognition & active recall, and learn what you’re curious about.

Vasili ShynkarenkaVasili Shynkarenka

Build a habit

Most people quit learning to code because they don’t get results. But results come after months of practice – there is no way to become a senior engineer after one hour of HTML tutorials. To get there, you can’t rely on fragile motivation that fades away quickly. You must build a habit of learning.

To build a habit, you need four things:

1. Design your intention.
2. Make learning time-based instead of outcome-based.
3. Start small.
4. Do not make up for missed studies.

Design your intention

Most people never study because they don’t specify when and where learning will happen. They just keep snoozing it because “today was really busy but let’s see if I can make it tomorrow.” And tomorrow never comes.

Intention design is a trick to help with indefinite plans. When you want to do something, write it down in the following structure:

“I, Vasili Shynkarenka, will study React course on Scrimba from 8:00 to 8:30 am tomorrow morning in my study room, right after I brush my teeth.” (Signature)

Here’s why it works.

First, you give yourself a word. When you promise yourself in writing that you will do something, you plant a seed for consistency. And humans naturally want to be consistent in their actions to not look stupid. But consistency works only if the action is present. And when you’re merely thinking about doing something, that’s not real yet. When you write the thing down, you make it real.

Second, you get clarity. Suppose you omit essential details, such as where you will be studying or which material you will use. In that case, you’re less likely to do it because you will experience increased cognitive load at the moment. Because humans don’t like thinking, you will go for the easiest option possible – to put it off.

That’s why Eisenhower famously said that while plans are useless, planning is essential. The act of planning clarifies subtleties. Your plan may change, but clarity will lower cognitive load and increase the likelihood of taking action.

Third, you specify the behavior after which learning should begin. Very often, our plans go sideways because we do not clarify when we will do the thing. Urgent stuff keeps popping up, and we never get to do what we wanted.

The easiest solution here is to choose a trigger that you already do every day, no matter what, and schedule your learning right after that act. Brushing your teeth, having breakfast, coming back home after work – all are excellent examples. If you approach intention design that way, you have less opportunity for failure because the “must-do” thing will always be there and serve as a reminder for the action you want to take.

Make learning time-based

If you choose to study until you finish the chapter, you incentivize yourself to optimize for speed rather than understanding. As a result, you will skim the most valuable parts to hit your goal.

The second problem with goals like “finish such and such tutorial” is that you will underestimate how much time it will take to finish the thing. And when you run out of time, you will be frustrated with yourself because you didn’t hit your goal.

Instead, set time-based goals. “Study JS course for 1h” is a good example. Or “Read new CSS tutorial for 30 min”.

When you switch to time-based learning, three things happen:

First, you take control of whether you succeed or not. When you are focused on the outcome, you have to rely on an unknown variable – how much time it will take for you to understand something new. This often leads to self-hatred – you will blame yourself for being stupid because you didn’t understand the material quickly. But if you focus on time, then you always succeed if you want to. You just need to focus.

Second, you can fit the learning session into your busy schedule. When you know that you’ll be learning for thirty minutes no matter what, you know where to put the thing.

Third, you build self-confidence. The time you spend on learning is a continuum, but the act of showing up is binary. It doesn’t care for how long you learn to mark it as “done.” And if you keep showing up for months, you become the type of person who shows up. And as most people quit in the first few months, you’ll have built immunity by the moment you will face The Suck.

Start small

When you’re just getting started, lower the time of your studies to a bare minimum. Make it negligible. Even ten minutes will do, given that you’re doing it every day.

I hear you saying: “How can I possibly learn something really complex as coding by spending ten minutes a day on it?” You can’t. But you can build discipline.

Also, you’ll procrastinate less. If you only have ten minutes to learn in a day, and there’s no opportunity to make up for it, your mind will be like: “Hell, I’ve got only ten minutes today – I better focus and not scroll Instagram.”

Do not make up

You must never, ever, make up for studies that you missed.

It’s incredibly easy to sell yourself on the idea that “Oh, I don’t really want to study this morning, I’ll do it later today when I have time.”

But snoozing is dangerous for two reasons:

1. First, you’re unlikely to do it later because you won’t have triggers to remember the thing. You screw up your intention design.
2. Second, you set up bad incentives for yourself in the future. There will be moments when your habit will fail you and you will skip learning. And if you’ve trained yourself to snooze things for later when any inconvenience arises, you’ll tend to do it over and over again. You’ll just keep snoozing.

So what do you do if you miss a session? Nothing. You don’t reschedule. You don’t blame yourself. It’s already in the past, so there’s no reason to do any of these things. You show up again tomorrow and do the work.

When you stop rescheduling, you become less likely to skip your learning sessions because you know you can’t make up for it. Your mind will remember the contract you have agreed on and stop offering opportunities for sloth.

Find your obsession

After you make learning a habit, the next question is how to get more of it. That’s because learning is nonlinear: if you put in two hours every day instead of one, you don’t get a 2x outcome – you get 5-10x.

The best way to allocate more time to coding is not to squeeze more hours of study but to discover your obsession.

Obsession is a multiplier for results. When you’re obsessed with something, you cannot not do the thing. As a result, you don’t have to decide each time whether to study or not. You just do it.

I’m obsessed with building interfaces. I don’t really care about how beautiful the app’s architecture is or what algorithm we use for compression. All I’m thinking about is how to make the user experience great.

When I realized that interfaces make me tick, I optimized my learning program to build more of them. I created all sorts of forms, confirmation alerts, and buttons. I stopped counting minutes I had yet to study and began going way beyond what I initially allocated for learning just because I was so curious about it. And that’s where real progress began to happen.

To find what you’re obsessed with, ask yourself two questions:

1. Why do I want to learn how to code in the first place?
2. Is there anything specific about coding that drives me?

If you don’t have an answer now, it’s okay. Try many things broadly to find what makes you tick about coding, and then double down in that direction. If data is your thing, go ahead and study APIs first. If you sweat when you make beautiful CSS animations, go and pick up that. Follow your own obsession.

The Suck

Everyone who learns something complex goes through The Suck.

That’s when things get tough. When you don’t see progress for weeks. When you wake up every day and question yourself if it’s worth it. When you are ready to quit. The difference between people who end up learning how to code and those who don’t is simple – those who succeed somehow manage to crawl their way through The Suck.

Because I knew how learning works, I was aware The Suck is coming. But it hit me hard anyway. To help you get through The Suck, I’ve documented what I did to pull myself from that shithole.

Understand how learning works

Learning is never linear and more like a giant exponential curve. It’s a weird one, with a flat part looking like a bumpy road. One day, you get a hit and go straight up. You learn something new. Another time, you spend many hours and get nothing.

Very often, it seems that you’re not making progress for days or even weeks. But you are. Think of it this way: if you try to blow a watermelon by putting a bunch of rubber bands on it, it’s not that one last band that makes all the difference, right?

Every single rubber band contributes to the final blow. Every single minute that you spend on learning makes you smarter. A minute alone doesn’t blow the watermelon of insight. But what if you add a few thousand?

Find an accountability buddy

It will be so much easier to crawl through The Suck if you team up with someone and make fun of it. The Suck will probably get scared and stop bothering you much. If you’re unsure who to ask, I’m making a group for self-taught devs where we keep each other accountable, ask questions, and have fun.

If you don’t have someone who holds you accountable, it will be hard to avoid sloth. If you think it’s just for puppies, you’re wrong. I’ve been training a friend of mine who runs a $300m company, and he told me afterward that the only reason he got up in the morning is that he promised me to show up for a run.

Build a life vest

When you want to quit, you’re likely stuck in a specific state of mind where everything looks black.

It’s like when your friend just broke up with someone. He thinks life is over, and he’ll never find a new girl who’s “that great.” And you’re telling him that he’s been through the same thing five times already, and there’s no way this is the last girl in the universe who’ll fall in love with him.

To prevent the consequences of this perception error, you need a life vest. Promise someone to have a conversation before quitting – any person who you consider rational will do. To make this even better, you can record yourself saying out loud all the reasons why you wanted to learn how to code in the first place and send it to the person right now. Or write down a list of arguments for persisting. That way, you will have a say against your future self.

If you really want to quit, email me right now with your phone number. I’ll call you back and try to convince you why you shouldn’t.

Misc

Below is the collection of thoughts that didn’t fit the main storyline. They’re standalone units and can be applied separately, although I think there’s a systemic effect of integrating all tricks.

Draw main concepts to improve understanding

When I’m studying, I always keep a piece of paper and a pen in front of me. If I don’t understand something or want to remember a particularly interesting concept, I begin drawing. I connect things together with arrows and lines and outline categories in boxes to add more meaning.

Paper works exceptionally well for sketching because it’s low-fidelity; I can switch between drawing and writing rapidly, and I don’t have to worry about making it perfect. In fact, high-fidelity tools work against creativity: my dad is a furniture designer, and despite having all sorts of tools like CAD, he still draws on paper because “it’s quick, dirty, and I’m not afraid to throw it away.”

When I’m drawing, I often apply metaphors. Analogies are a potent tool for better thinking because they connect psychologically distant ideas, which is essentially creativity. So when I’m making a drawing, I try to make a fun analogy of the concept or incorporate it into some real-world object. This helps me remember the idea better – I’ve found that I recall ideas with drawings 2x better than concepts that I didn’t sketch.

For example, when I studied how virtual DOM works, I drew two houses – because “DOM” is a “house” in Russian – where JSX elements lived. And I made one of the houses a hologram to create a metaphor for “virtual.”

If you’re curious, you can look up some of my drawings here. If you’re interested in improving your drawing skills, you can get much better by drawing 30 min daily for 30 days. Don’t forget to apply the habit process from part one.

Improve transfer by creating more hooks for recall

When you’re learning how to code, you’re actually doing two things:

1. You’re learning to think like an engineer to understand what the program should be doing.
2. And you’re memorizing symbols to instruct a computer on how to do the thing.

You can think of these two parts as “what” and “how” of coding – knowing what to do and knowing how to do it.

The “what” part is underrated. If you take a bunch of coding bootcamp grads, most of them will know the “how” part reasonably well – they’ve learned the symbols. But if you give them a real-world problem to solve, students will stare at a screen blankly for hours, not having the slightest clue “what” the program should be doing.

Figuring out how to apply the knowledge you have learned to a problem at hand is called the transfer problem. It’s the most challenging part of learning anything – but there’s a trick to improve it.

When you grasp a new concept, ask yourself: “What other things does it look like?” as a part of your reflection questions. When you consciously think about it, you create more “hooks” for future recall – you connect ideas together.

That’s what John Tukey did, as Hamming tells us in his lecture on creativity. Tukey always outsmarted Hamming by coming up with seemingly obvious ideas when Hamming just couldn’t think of them, although he knew the subject just as well as the Tukey did.

Here’s how Hamming explains Tukey’s success:

I worked with John Tukey for many years. He was clearly a genius, and he used to infuriate me frequently.

We’d be doing something, and he said: “Well, you know about the polarized light?” And I was, “Well yeah, I know about polarized light. But it didn’t occur to me to think of the situation where that would be relevant for our radar.”

Why didn’t I think of it? Partly, of course, he was smarter than I was, but partly he had done something I had not done.

Up until then, I had learned things in the framework in which I had learned them. But then I saw that when he learned something, in the act of learning, he asked himself: “What other things does it look like?” In other words, he put little hooks on the idea, so it had many. And I could only recall the idea in the framework in which I learned it.

You see the difference? If you simply learn in the framework which you’re told, you can recover in that framework. But if you think it over yourself and associate with many other things in your mind, then when the time comes to recall it, there are many more hooks, and you can pull up the fish the other guy misses. And this is what John did.

I believe the transfer question worked so well for Tukey because the number of connections between ideas grows exponentially. If you add just three new links a day, you actually add way more – because those three ideas connect to many others in your mind.

Another trick to create even more analogies in learning is to have keyboard shortcuts that make it easy. For example, I have a “tf” shortcut that expands into “this reminds me of.” That way, I make it easy to capture a connection right in the moment of inception.

You can read more about my use of shortcuts here.

Focus by avoiding distractions

Coding requires immense concentration because you need to build a complex mental model in your head of how the program works to implement it. If you’re studying something sophisticated, like how JS runs in Chrome, you need to tie all these pieces together to really understand it. And you can’t do it if your phone is buzzing every few minutes.

When most people try to concentrate, they consciously do this by commanding themselves – “focus, you idiot!”. But focus is like sleep; if you push it too hard, it doesn’t come.

Instead of trying to focus, I eliminate things that distract me. It’s a simple but useful trick, and I haven’t read much about it. Here’s what I do to get rid of distractions:

• Wake up early to work when everyone’s sleeping. I wake up at 5:30-6 with no alarm and begin studying right after finishing my workout. This gives me a good 1-2h of study before the day really begins, which is great for two reasons. First, there are no distractions from the outside world, like calls, meetings, etc. And second, it feels so good to log 1-2h of studying – which is really investing in my future self – before the day begins. I feel like I’ve done something important already, which sets me up for more ambitious tasks.
• Do not have comms apps on my phone. If I could give someone only one tip on how to be happier and more productive, this would be the one – delete all communication apps. A few months back, I’ve discovered that I’m severely addicted to checking email and messages on Telegram. I’ve tried doing less of it but failed miserably; every time I had a second, I found myself checking if anyone sent me something. I deleted everything from my iPhone and moved all communications to a separate Google Chrome account to avoid such misery. That way, I have more “walls” between me and the app. I’ve found that having these walls is immensely helpful because even when the urge wins, and I give up and go check my inbox, I have to come through difficulties that remind me that I actually didn’t want to be a person who behaves that way.
• Use News Feed Eradicator Chrome extension. The last wall of defense against the cheap dopamine is within the network itself – the extension cuts out the feed and replaces news with anything you want. I used to have custom messages, but now I have the quotes they offer by default – they’re quite good.
• Listen to ambient, soothing music in noise-cancellation headphones. When I lived in a tiny one-bedroom apartment and my wife was making sales calls a few meters away, I always put on my Bose QCII headphones with some ambient piano to concentrate. I’ve experimented with many Spotify playlists but found two that work best for me: Intense Studying for studying and Lo-Fi Beats for coding.
• Keep a variation of a maker’s/manager’s schedule. I split my days into three days: 8-12, 2-6, and 7-9. On the first day, from 8 am to 12 pm, I only do focused mode work – writing, thinking, and studying. I’ve found that I’m most creative in the morning, so I try not to waste that time. From 2 to 6, I do everything else that needs to be done; and from 7 to 9, I usually reply to comms and do ops/comms work. When my days are scheduled that way, I procrastinate less because I proactively choose to not do certain things at a particular time and feel perfectly fine about not doing them. Another benefit of a three-day schedule is that if I waste a sub-day for some reason, there’s still two more to go!

Progress

In a few months, you’ll begin seeing progress. When you realize for the first time that you can actually program something, you become unstoppable. That’s why I put so much emphasis on crawling your way through The Suck; because your whole goal is to not quit early. If you succeed, you will not want to quit because you’ll know how incredible it feels to make something yourself.

It’s like getting fit in that sense. When you see a real, physical change in the mirror, you understand the whole thing wasn’t a waste of time.

For me, the epiphany came when I was building a movie search app in React. The very second I saw the problem, I knew the solution in my head. I just knew how to do it. I knew that I needed a few components, how to fetch data from the API, how to store user input in the state, how to pass data between my components to render the JSON that comes back from the API. All these tiny pieces that I’ve picked up over the weeks of learning merged together, and the dots connected.

To sum up: make it a habit, find an accountability buddy to not quit in the first few months, and try many things to discover what makes you tick about coding. Once you discover it, follow your own obsession. And remember – every day you don’t quit, you get closer to knowing how to code.

Remember what you just read

If you answer the questions below, you will create new neurons in your head via neurogenesis. If you don’t, you will forget about 80% of what you just read tomorrow morning.

Reading without reflecting is wasting your time. Don’t do that.

• How to build a habit of learning?
• What are the four components of building a habit?
• What does intention design mean?
• Why should learning be time-based instead of goal-based?
• How starting small helps to learn better?
• How does making up for missed studies affect learning?
• How do you get through The Suck?
• How drawing helps to learn?
• How to improve transfer in learning?
• How should you approach focusing?

Thanks for reading my work.