How to learn this without burning out

The only lesson here with no code in it

You have built and installed a real app. That already puts you ahead of most people who ever downloaded a programming course.

Next comes the stretch where it gets genuinely hard and most people quietly stop — not because they cannot do it, but because nobody warned them what learning to code feels like from the inside. So: one warning, and six habits.

The warning is that confusion is not a signal that you are failing. It is the sensation of your brain building something it did not have before. Everyone gets it. The people who keep going are the ones who were told in advance that it was normal.

Six habits

1. Twenty minutes, most days

Short and frequent beats long and rare. One lesson a day finishes this whole course in about eleven weeks, and you will still remember Part 1 when you reach Part 5.

Pick a slot attached to something you already do — the bus, after dinner, before bed. A time you do not have to decide about is a time you actually turn up to.

2. Type the code. Do not paste it.

There is a copy button on every code block here. It exists for the long blocks in Part 5, where retyping forty lines teaches you nothing.

Type everything shorter. Typing drags you past every character your eyes would skim — the capital T, the closing brace, the comma. It is slower on purpose; the slowness is the lesson.

3. Treat confusion as the work, not the obstacle

Reading a line four times and still getting nothing is not wasted time. It is the time. What helps: read the two lines around it, say it out loud in plain English, then carry on. Understanding often arrives two lessons later, in retrospect, all at once.

4. The twenty-minute stuck rule

When an error has beaten you for twenty minutes, stop. Not forever — for now.

Before you close the app, write down three things: what you were trying to do, the exact error text, and what you have already tried. Thirty seconds of writing.

Read your own note tomorrow. Surprisingly often you will see the answer in ten seconds, because you are no longer the person who has been staring at it. Professionals use this daily.

5. Change one thing, then build

On a phone a build costs you minutes, battery and, on the Free tier, one of a limited number of builds. So batch your thinking: make a change, read it back, check for red underlines, then press Run.

Plug the phone in before a session. If it gets hot, put it down for two minutes — a hot phone slows itself down, and a slow build is a build you will be tempted to interrupt.

6. Build one tiny thing of your own each week

Not from a lesson. Something small and slightly pointless that you thought of. Change Hello Pocket to show the time. Make it count your taps. Ten minutes of your own idea beats an hour of following instructions, because it forces you to retrieve what you know rather than recognise it.

Keep the receipts

Today you built and installed an app. In three weeks that will feel unremarkable, which is a shame, because it is not.

Use Git as a diary. Every time something works, make a commit whose message says what now works. Ten seconds each. It gives you a way back when you break something, and after a month you have a dated list of everything you have achieved, in your own words — which is worth a great deal on the days it feels like you are getting nowhere.

What is coming

An honest map, so nothing ambushes you.

Two pieces of permission you are unlikely to be given elsewhere:

You may skip ahead. If Part 4 is grinding you down, jump to Dice Duel in Part 5 and build something. Come back when you want to know why it works. Motivation is a resource and it is allowed to steer.

You may not remember things. Nobody holds all of Kotlin in their head. Looking a thing up for the fifth time is not failure — it is how it is done, by everyone, permanently. The glossary in this course exists precisely for that.