As a developer, I really like the feeling of building something that people can actually use. You put it in their hands, they give you feedback, and you keep improving it. But getting something working can also hide a lot of things you don't understand yet. You follow a tutorial, connect a few tools, fix the errors, and the project runs. Then you try to change one part of it and realize you can't explain why it worked in the first place.
Going back to what we missed
I think we do this with learning more often than we admit. We finish the course or pass the exam and assume we're ready for the next thing. And sometimes we are. But sometimes we carry a small gap into a much harder problem, where it becomes difficult to even recognize what we're missing. Someone struggling with algebra might need more practice with fractions. In programming, you can spend hours fighting a framework when what you don't understand is how an asynchronous function behaves.
Going back feels weird because we attach a lot of meaning to the level we're supposed to be at. If you've already built an application, opening an introductory lesson can feel like admitting you didn't deserve to build it. I don't think that's a useful way to look at it. The application exists, and so does the gap. You can be good at parts of your work and still need someone to explain something basic. I'd rather know exactly what I'm missing than keep finding ways around the same problem.
Getting it working, then understanding it
That also changes what practice should look like. Let's say you're learning how requests work in a web application. Reading an explanation is a start. Then try sending a request yourself, change the input, look at the response, and make it fail. Explain what happened without copying the documentation. Come back a few days later and try a slightly different version. You're checking whether you can use the idea when the original explanation isn't sitting next to you. And when the basic steps become familiar, you have more attention available for the harder decisions in the project.
With LLMs, I think we need to be even more deliberate about this. You can ask for an explanation, get another example, or have a model help you find the step you missed. That's useful. You can also have it complete the entire task while you understand very little of what happened. Both can produce a working result, but they leave you with different abilities afterward. When the goal is learning, I still want to read the code, change it, and see what breaks. A generated answer can give me something to investigate; I have to do that investigation myself.
Learning with other people
There's a human part to this too. Being told to work harder doesn't help much if you don't know where to start. A good teacher or mentor can keep the expectations high while helping you find a problem you can work through. And making mistakes in that situation is easier when you don't feel embarrassed about asking. You get to build confidence from solving something that was difficult for you, then take on the next problem. That progress deserves attention even if someone else started much further ahead.
This is also why I like workshops and communities where people leave with something running. A project gives the practice a purpose, and other people give you feedback you wouldn't get on your own. The project might be small, but someone trying to use it will quickly show you what needs more work. You learn the basics, use them, discover another gap, and go back with a better reason to understand it. I'd like us to make more room for that, including the part where an experienced person says, “Wait, I don't understand this yet,” and gets to work on it.
Reference: How to Accelerate Learning & Improve Education, with Joe Liemandt — Huberman Lab.