Your First 30 Days Learning to Code: A Week-by-Week Beginner Roadmap

Thirty days is an odd unit of time. Long enough to build a habit, short enough that the finish line stays visible. That is exactly why it works for a first month of coding.

What follows is a week-by-week plan built around roughly one hour a day, five days a week. Each week has a single goal, a short list of exercises, and free resources you can open in a browser tab. No subscription, no bootcamp, no prior experience. By day 30 you will have a small working project and, more usefully, a routine you can keep.

One rule before you start: pick one language and stay with it for the whole month. JavaScript, run in the browser console, or Python, run in the terminal, are both sensible first choices. Switching mid-month feels productive and teaches you almost nothing, because you keep re-learning the same beginner concepts in new syntax.

Week 1: Get Code Running and Learn Four Things

The first week is mostly about removing friction. Install one code editor, get your language running, and learn how to run a single file. If that takes an evening, that is a normal evening.

By Friday you want to be comfortable with four ideas: variables, conditionals, loops, and functions. That is the whole syllabus. Almost everything else in programming is those four things arranged in more interesting ways.

Exercises that actually stick

• A temperature converter: read a number in Celsius, print the Fahrenheit equivalent.
• A greeting program that asks for a name and an age, then prints a message with a rough birth year.
• FizzBuzz up to 50. It is a cliché because it forces you to combine loops and conditionals in one place.
• A grade calculator: given a score, print a letter grade. Then wrap it in a loop that repeats until the user types "quit".
• A times-table printer for whatever number the user enters.

Free resources for week one

freeCodeCamp's JavaScript curriculum and Python's official tutorial both start from zero and expect nothing. If you prefer video, the CS50x lectures are free to audit and give you a sense of how a computer science course is taught. Bookmark MDN Web Docs for JavaScript reference; you will use it for years.

Two habits to build now. Type every example by hand instead of copying it, because your fingers learn the syntax faster than your eyes do. And break things on purpose: delete a semicolon or a closing bracket, run the code, and read what the error says. Errors are not punishment. They are the main way the computer talks to you.

Week 2: Data, Functions, and Programs That Respond

Week two moves you from scripts that run once to small programs with structure. Add lists (or arrays), dictionaries (or objects), functions with parameters and return values, and user input that changes what happens next.

Five exercises, one per day

1. A word counter: paste in a sentence, print the word count and the longest word.
2. A menu-driven unit converter that loops until the user chooses to exit.
3. A number guessing game with "too high" and "too low" hints and an attempt counter.
4. A tip splitter: take a bill, a party size and a percentage, then print the amount per person rounded to two decimals.
5. Refactor one of last week's exercises into three separate functions. Same output, cleaner shape.

If a function grows longer than a screen, that is a signal to split it. Naming matters too: calculate_total tells you more than doStuff, and future-you is the person most likely to be confused. Exercism and Codewars both offer free beginner exercises with community solutions you can compare against your own once you have finished.

Week 3: Break Problems Into Steps, and Learn to Debug

This is the week most beginners stall, and it is rarely about syntax. It is about looking at a blank file and not knowing where to start.

Write the steps before the code

Take any feature and describe it in plain numbered English first. For a to-do list: show a text box and a button; when the button is clicked, read the text; if the text is empty, do nothing; otherwise add it to a list; redraw the list. Then translate each line into a few lines of code. The blank file problem disappears because you are never writing a program, only the next line of a list.

Debugging rules worth memorising

• Read the error message properly. It usually names a file and a line number, and that line is where you start looking.
• Change one thing at a time. Three simultaneous edits teach you nothing about which one worked.
• Print values as you go. If a loop misbehaves, print the counter and the result on every pass.
• Explain the code out loud, line by line. You will hear the mistake before you see it.
• Search the exact error text in quotes. Someone has almost certainly hit it before.

Start using version control

Install Git and create a free GitHub account this week. You need three commands at first: git add, git commit -m "message", git push. Commit once a day. Even with no collaborators, having a history means you can return to a version that worked instead of guessing.

For practice, rebuild a week-one exercise from scratch without looking at your old file, solve three easy exercises on Exercism, and take a working program and deliberately break it in five different ways, fixing each one.

Week 4: Build One Small Project and Finish It

The project is a to-do list. Boring on purpose: small scope, obvious features, and it forces you to handle input, stored data and display all at once.

The minimum version

• Add a task from a text field.
• Show every task.
• Mark a task as done.
• Delete a task.
• Keep the tasks after a refresh, using local storage in the browser or a JSON file in Python.

If you chose Python, build the same thing in the terminal: print the numbered list after every command, and accept add, done, delete and quit. Same logic, no styling.

Spending the five days sensibly

Day one on paper: sketch the screens, list the functions, decide what is out of scope. Days two to four on building, one feature per session, committing after each. Day five on rough edges and a short README explaining what the project does and how to run it. Then ship it, even if it is only a repository nobody else has seen.

Finished beats impressive at this stage. A to-do list that works teaches you more than a half-built social network.

What to Do When You Get Stuck

1. Give it fifteen focused minutes. Re-read the error and the last thing you changed.
2. Cut the problem in half. Comment out sections until the smallest failing piece is visible.
3. Search using the error text plus your language name.
4. Ask in a community forum, pasting the code, the full error, and what you already tried.
5. Move on and come back after a walk. Fresh eyes solve a surprising number of bugs.

Keep a plain text file of every bug you fix and how you fixed it. After a month it becomes your own reference manual, and it is far more useful than a generic cheat sheet because it records the mistakes you actually make.

Where to Go in Month Two

Do not switch languages. Instead, choose a direction and go deeper for the next thirty days. Front-end work means HTML, CSS and the browser. Back-end work means servers, requests and a database. Automation means small scripts that handle repetitive tasks on your own machine. Any of the three uses what you already learned this month.

Then build two more small projects, and read other people's code on GitHub for twenty minutes a week. Keep the daily habit small enough to survive a bad day: twenty minutes still counts. The people who stick with programming are rarely the fastest starters. They are the ones who show up on the days when nothing works.

Photo: RDNE Stock project / Pexels