Practice That Sticks: Projects, Exercises, and Study Habits

This is an independent educational guide, not the website of any school or course provider.

koderich.com is an independent, non-commercial field guide to learning programming. It explains how code works, how beginners choose a first language, how to practice effectively, and the vocabulary of software development. It sells nothing, runs no courses, accepts no advertising, recommends no specific paid product, and has no affiliation with freeCodeCamp, CS50, MIT OpenCourseWare, MDN, the ACM, or the IEEE Computer Society, or any other named organization.

You have watched the video. The instructor typed a loop, explained it, and moved on. You nodded. Then you opened a blank file and your mind went blank. That gap is normal, and it is the entire subject of this guide. Reading code and writing code are different skills, and only one of them builds the other. What follows is a set of working principles, a few free curricula that already exist, and a decision table for the days when you cannot tell whether you are stuck or just tired. No accounts, no purchases, no promises about jobs. Just practice that sticks.

1. Why practice is the learner's responsibility

A tutorial can show you a technique, but it cannot perform the technique for you. Watching someone else type for (let i = 0; i < 5; i++) teaches you the shape of a loop. Writing that loop yourself, changing the bound, breaking it on purpose, and watching the error message appear teaches you what the loop does. The difference is not motivation. It is that your hands and your attention are doing different work when you type versus when you watch.

Errors are where the learning happens. A missing semicolon, a variable spelled two ways, a function called before it is defined — each one forces you to read the code as a machine reads it, not as a story you half-remember. That reading is the skill. Nobody can do it for you, and no course can compress it into a lecture. The good news is that the work is small and repeatable: open a file, write ten lines, run them, fix what breaks.

2. The working principles of effective practice

Four habits do most of the work. First, keep exercises small and complete. A program that asks for a name, stores it, and prints a greeting is finished; a half-built to-do app is not. Second, introduce one new concept at a time. If you are learning arrays, do not also learn classes in the same session. Third, type code by hand instead of pasting it. Pasting skips the moment where your fingers hesitate, and that hesitation is a signal about what you do not yet know. Fourth, finish each week with an artifact — a file you can run, a page you can open, something that exists outside your notes.

Illustrative example: a four-week plan for a beginner learning JavaScript. Week 1, a number-guessing game in the browser console. Week 2, a tip calculator with a form and a button. Week 3, a small quiz that stores three questions in an array. Week 4, a weather-lookup page that reads a public API and displays one value. Each week ends with a file you can open and use. The names are invented; the shape of the work is not.

3. Free structured curricula that exist today

Several free, well-known curricula are available if you want a sequence rather than a pile of tutorials. freeCodeCamp publishes a full curriculum with certifications earned by completing projects. You work in the browser, and the projects are the assessment. CS50 is Harvard's free introductory course, with lectures and problem sets that ask you to write real programs in C and then in Python. The problem sets are the point; they are where the concepts become yours. MIT OpenCourseWare publishes actual MIT course materials — lecture notes, assignments, exams — for self-study, without enrollment or credit. Each of these is free to use and independent of this site. Pick one and finish a unit before sampling another.

4. Projects that teach

An exercise tells you what to build. A project makes you decide. The moment you start a project, questions appear that no exercise asks: What should this file be called? Should this logic live in one function or three? Where does the data come from? Those decisions are the work of programming, and they only surface when the shape of the program is yours to choose.

Documentation is the tool for those moments. When you cannot remember how Array.prototype.map behaves, you look it up rather than guess. MDN Web Docs is the standard reference for HTML, CSS, and JavaScript, with syntax, parameters, and examples for each feature. Reading a reference page is a skill in itself: find the method, read the signature, check the return value, try the example. Do that three times and you will stop fearing the blank page.

5. Reading other people's code

Open-source projects are readable by anyone with a browser. You do not need permission, an account, or a maintainer's blessing to open a repository and read a file. Start with a small utility, not a large framework. Read one function at a time and ask what it takes in and what it gives back. You will meet conventions you have not seen — folder layouts, naming patterns, comments that explain why rather than what.

For a wider view of how practitioners describe their work, the professional societies publish material aimed at working engineers. the ACM publishes magazines and journals that discuss software design, algorithms, and practice. the IEEE Computer Society publishes magazines and research across computing fields. You do not need to read them cover to cover. Skim an abstract, notice the vocabulary, and move on. The goal is familiarity with how the field talks about itself.

6. A decision table

Use this when you are not sure what to do next. The situations are general; the actions are habits, not products.

7. Frequently asked questions

How do I know I am actually learning?

You can build something small without following a tutorial. If you can open a blank file and write a program that runs, the practice is working. If you can only follow along, keep going.

Should I finish every exercise?

Finish the small ones and abandon the ones that no longer teach you anything. The goal is a finished artifact, not a perfect record.

Is it bad to look up the answer?

No, as long as you type the solution yourself and then change it. Looking up syntax is normal. Copying a whole solution without reading it is not practice.

How much should I read other people's code?

Some, regularly. One function a day from a small open-source project is enough to build familiarity with conventions you will not see in tutorials.

What if I miss a week?

Restart with a small exercise, not a large project. Rebuilding momentum is easier when the first task takes twenty minutes.