Feeling busy and getting better are different things. Judge progress by what you can do without help that you could not do a month ago: build, debug, explain and solve. Set monthly checkpoints, redo old problems cold, and swap passive study for work that produces evidence.
What people tell me
I study almost every day. I watch courses, read articles, follow tutorials and take notes. But when I try to build something on my own or solve a new problem, it feels like I am in the same place I was months ago. I cannot tell if I am improving slowly and just not noticing, or if I am wasting my time. It is making me anxious because I am putting in the hours and not seeing results.
A composite of the messages behind this question, with personal details left out.
Key takeaways
- Hours studied is an input. Progress is what you can now do without a tutorial, AI or hints.
- Passive study (watching, reading, copying) feels productive but builds recognition, not skill.
- Set monthly checkpoints: a small project from scratch, a set of unseen problems, a bug to fix, a concept to explain.
- Redo work from a month ago without help. If it is easier, you have improved.
- Keep a learning log. Progress is hard to feel day to day and easy to see over eight weeks.
Busy and better are not the same thing
This question usually comes from people who are working hard. That is what makes it painful. The hours are real. The problem is that a lot of study time goes into activities that feel like learning but mostly build recognition: you see an idea explained and it makes sense. Recognition is not the same as being able to produce the idea yourself on a blank page.
So the first step is to stop measuring effort and start measuring ability.
What real progress looks like
Ask yourself whether, compared with a month ago, you can do more of these without help:
- Start a small project from an empty folder and get it working.
- Read an error message and find the cause yourself.
- Solve an unfamiliar problem of a type you have practised.
- Explain a concept, such as how a request reaches your server, in plain words.
- Read someone else's code and say what it does.
- Estimate roughly how long something will take and be close.
If the answer to most of these is "not really", your study method is the problem, not your ability.
Audit how you spend study time
Track one normal week and put each session into one of two columns:
| Passive (feels productive) | Active (builds skill) |
|---|---|
| Watching a course | Building a feature without the video open |
| Reading articles | Writing a short explanation in your own words |
| Following a tutorial step by step | Rebuilding the tutorial project from memory |
| Reading solutions | Attempting problems for 30 minutes before looking |
| Asking AI to write the code | Writing it yourself, then asking AI to review it |
A healthy split is something like one third passive, two thirds active. Most people who feel stuck are at nine tenths passive.
Set monthly checkpoints
Once a month, give yourself a short test that you cannot fake:
- Build test. A tiny app in two to three hours with no tutorial, for example a to-do list with a backend, or a page that fetches and filters data.
- Problem test. Five problems you have not seen, timed, no hints.
- Debug test. Take one of your old projects, break something deliberately or pick an open bug, and fix it.
- Explain test. Write a one-page explanation of something you studied this month, as if teaching a junior.
Write down the results. Next month, repeat with similar difficulty. That comparison is your real progress chart.
Redo old work cold
One of the simplest and most encouraging tests: pick a problem or small project from four to six weeks ago and redo it with no help. If it feels easier, faster or cleaner, you have improved, even if new material still feels hard. New material always feels hard. That is what makes it new.
Keep a learning log
Every day, one or two lines: what I did, what I got stuck on, what I understood. It takes two minutes. After two months, read it from the start. People are consistently surprised by how far they have come, because the change was too gradual to feel.
Signs your method needs to change
- You finish courses but cannot build anything similar without them.
- You recognise solutions instantly but cannot produce them.
- You rely on AI for most of the code and cannot explain parts of it.
- You keep switching topics before going deep on any.
If two or more apply, keep the same hours but move most of them into active work. You will feel slower for a couple of weeks. Then you will actually be faster.
A worked example of a monthly checkpoint
Say you have spent a month learning backend development with Node.js. A useful checkpoint on the last Saturday of the month might be:
- Build (two hours): an API with three endpoints for notes: create, list, delete, stored in a real database. No tutorial open.
- Debug (thirty minutes): rename a column in the database and fix everything that breaks, using only the error messages.
- Explain (twenty minutes): write half a page on what happens between a browser request and your database query.
- Problems (one hour): five easy problems you have not seen.
Record the time each took, where you needed to look something up, and what you could not finish. Next month, run a checkpoint of the same size on the next topic. If you finished more, looked things up less, or your explanation was clearer, that is real progress, whatever your feelings say.
A weekly self-check in three questions
Every Sunday, answer in writing:
- What can I do now, without help, that I could not do last Sunday?
- Where did I get stuck, and did I get unstuck myself or did someone (or AI) do it for me?
- What was the ratio of building to watching this week?
If the answer to the first question is "nothing" for two weeks running, change the method before adding more hours. If the underlying problem is too much to cover, where to begin when there is too much to learn covers how to cut it down.
If you are still stuck
Read What to do when you are stuck learning to code and How to use AI as a companion, not a crutch. The resources library has practice material for the monthly checkpoints. If you want someone to look at your specific situation and review your progress honestly, join Sefism and, as a member, book a 1:1 session.
Was this answer helpful?
Read next
- What to Do When You Are Stuck Learning to CodeThere has never been more good material for learning to program and the failure rate has not improved, which tells you the bottleneck is not access to explanation. It is that watching someone else solve a problem feels exactly like learning and is not. Sixteen heuristics for the first year, mostly about what to do at the point where you are stuck.
- How to Use AI as a Companion, Not a CrutchOne rule decides whether AI tools make you faster or hollow you out: use them for work you could do yourself but would rather not, and for work you are actively trying to understand, never for work you cannot evaluate. Where they genuinely excel, where they quietly damage your skills, and the verification habits that separate engineers who benefit from those who accumulate debt.
- The Fundamentals Worth Learning as a Software EngineerFrameworks are the fastest moving and least valuable part of what you know. This is the layer underneath: how a computer runs your code, data structures as trade offs, complexity at conversational depth, storage, networks, concurrency, version control, testing as a design tool, and the two skills engineers skip that decide how far they get.
Your situation is not quite this one?
Members get written answers to their own questions, a roadmap built for them and feedback on their projects. Early access is open to X and Instagram followers and university students. Prefer to talk? A free call works too.