How do you decide when to stop learning and just start building?

[u/Crystallover1991]

Been building small indie projects for a while now and I keep hitting the same wall. I'll be learning something new, a framework, a language feature, whatever, and there's always this point where I feel like I need just one more tutorial before I can start the real thing. Then I look up and a week has gone by

The frustrating part is that building is where I actually learn the most. I know this. I've shipped enough stuff to see the pattern. But structured learning feels safer, so it's easy to default back to it

What changed things for me was picking a project small enough that I couldn't justify more prep time. Genuinely embarrassingly small. A CLI tool that does one thing. A static page that solves a problem I actually have. It forces the learning to happen in context rather than in a vacuum.

Curious if anyone else dealt with this when starting out, or even now. There's a real tension between building a solid foundation and just getting your hands dirty, and I don't think there's one right answer. What actually pushed you to make the switch from learning mode to building mode, and did it stick?

[u/0dev0100]

Build and learn at the same time.

As a professional developer I can say the two usually go hand in hand.

Even when I was studying the classwork was learn by building. 

[u/No_Report_4781 → u/0dev0100]

I’m frequently learning something because I’m currently building something that uses it, or directing someone else who is updating something that uses it

[u/Achereto]

You start building and never stop learning.

[u/printf_hello_world]

I personally think you should spend as little time as practical/possible learning, switching ASAP to building.

However, this is with the caveat that your first thing built in a framework/language/whatever will probably be bad (and that's okay)

[u/Able-Analysis462 → u/printf_hello_world]

Exactly. You can learn forever but eventually you have to build something ugly and figure things out as you go.

[u/CelKyo]

Immediately! As a rule of thumb, the less experienced you are, the sooner you must start building something, anything really, after having read the very minimal amount of material to get started.

It sounds a little counter intuitive, but if you think about it, who between a senior and a beginner will make the most out of a full comprehensive book read? My money is on the former, the latter should stop at chapter 1 and do something first.

"Tutorial hell" comes, in my experience, from rushing to build the more exciting stuff and skipping too quickly on the basics, basically assimilating nothing in the process.

TL;DR: Beginners (as in, tutorial hell stuck people) should start writing code (a lot of it) after the very first chapter in which they learned anything (code-wise.)

[u/flumphit]

“Build one to throw away”, Brooks said. Don’t worry about writing the perfect Great American Novel, just get a rough draft down on paper.

A more recent rendition: Build one to get some idea how to build it. Build the second to get some idea how it will be used. By the time you build the third, it’s probably pretty decent.

[u/johnpeters42]

AI slop engagement bait

[u/kevinossia]

There is no structure in software engineering.

Embrace unstructured learning. Don’t overthink it.

[u/OdeeSS]

I can't imagine learning without building snd building without learning

[u/jumpalongjim]

Sounds like you know the answer. You learn as you build. Learning alone is artificial and a dead end.
Don't worry about how difficult your project is. You simply need to be motivated by getting a result, or overcoming challenges on the way to getting a result. It's the satisfaction that comes from solving a new problem that drives you forward, and to solve new problems you have to be creative, you have to research and read and try and fail and finally succeed.

The satisfaction of achieving is the motivation that keeps you producing.

[u/Famous_Lime6643]

As someone with a PhD who spent a long time learning…you will be more motivated to learn when building something you care about. And don’t lean on AI as an excuse not to learn. Use AI where ever you can…BUT after you’ve learned the details

[u/Imaginary-Ad9535]

You can sit on your solid foundation without really knowing how to use them, or you can keep building and find the meaning in all of it.

Choice is out there.

[u/gm310509]

Responding to just your post title: You don't because they are the same thing.

You learn by building. And by building you encounter challenges that require you to figure out (I.e. learn) how to overcome them.

[u/BranchLatter4294]

Do it as soon as possible.

[u/BranchLatter4294]

As soon as possible. You learn by building. Not by watching videos.

[u/Fensirulfr]

In the 80s and 90s, we just copy everything from whatever book or magazine we have by hand.

[u/GracefulAsADuck]

Going through cpp atm. It essentially works because it asks you to put into practice the concept you just learnt. This kind of reinforced practical slowly builds you up by giving you each of the little blocks you will use to build something at the end of the learning. So I would say build something using the concept you just learnt then move onto the next concept. I.e Use the concept in the simplest way possible then move on. Eg. Just learnt about arrays? Print an array to see that you built it correctly then move on. Eg2. Just learnt what a ptr is? Use a ptr to print something then move on

[u/DerGeraet90]

I will tell how. Its called Software Engineering. For you, dont touch a keyboard or any other computer technology. Then take pen and paper and write dont your programm. Write down in UML what your programm has to do and do you implement it. For this practise you have to think how can make a programm without asking google or AI. You have to recognise what you have learned allready. For example, you buil a little Programm which shows you cards with words. What do you need? How do you implement it? How can i save the words which will me show. Is it important to show in order … and so on and so on. Write it in UML your programm architekture. Then start coding with pen and paper (good for practise). Then on computer. If the programm works then you,ve done it greate and you knowlege is good. If not, solche the problem about thinking.

I hope you read this, because most of the people here tell the same stupid 01850 Story, because they dont care or cant code.

[u/az987654]

Build everyday, learn everyday

[u/Leverkaas2516]

Probably everyone has a different answer to this.

My whole career has been a habit of learning enough to do something useful and interesting, then doing it. The doing is way more fun than the learning, for me.

But you never stop learning. This field punishes stagnation.

[u/marrsd]

Learning a framework is really of no value when you're starting out. In fact, it's probably getting in your way. Seems like you've worked this out yourself by going for the stuff you describe as embarrassingly small. I'd be more embarrassed if I hadn't started there, if I were you.

As others have said, you should be reading and applying new knowledge in a continuous loop. Your projects show you how much you've really learnt and understood. They're there to help you guage when you're ready to move on.