How to approach project-based learning?
Posted by ahmed_kitsuragi@reddit | learnprogramming | View on Reddit | 4 comments
I am hesitant to which way has better outcomes for learning how to build real things:
1- Start with small projects (http server, rate limiter ...) and build up from there. Dive into the technical details of each one and take time doing so.
2- Try to build a full-fledged application or system. Divide it into smaller problems, work on a single one at a time and revisit the old ones if you learn a new thing. Rethink design choices whenever you hit a major roadblock and iterate until the end result is good enough.
Which method worked best for you?
_N-iX_@reddit
Both approaches work - they just teach you different things. Small projects are great for understanding concepts in isolation and building intuition. Bigger projects are where you learn how things actually fit together: architecture, trade-offs, and iteration. It’s usually more effective to treat it as a sequence, not a choice. Start with a few focused mini-projects to get comfortable, then move to a larger system where you apply everything and refine your design as you go.
The second approach is closer to real-world work, but it can get overwhelming if you jump into it too early. A good middle ground is building something slightly bigger than you’re comfortable with - like a small app with an API, database, and some core features. Big enough to learn system thinking, but still manageable to finish and iterate on.
Shadow-Raleigh@reddit
I don't think it will matter that much, but at least for me, the most engaging method was to make "incomplete applications" of increasing complexity.
For example, when I just started learning python as my first language and barely knew how functions and objects worked, I decided to make a terminal basic roulette game, where you could only bet on a single number or on a color. It worked, I had fun and learned a lot at the same time. From there, I built upon it, adding features and making it look and run better, until I was satisfied with it. On this project, I never left the terminal, but that was fine because my first objective was to train my logic and understanding of basic sintax.
Then, I decided to make something more complex, and add an interface. And every project after that was a new program with a new challenge to beat.
Again, from a learning perspective, as long as you're building your own stuff, it will probably be similar, but, at least for me, building something incomplete, so than I can think of building upon it to make it more complete and interesting is more engaging than just making a single component, while being less overwhelming than setting yourself for a full project from the get go.
Also, sometimes a project isn't all that interesting overall, and if you set a "success threshold" of "an incomplete program, as long as beat this one technical challenge" you might quit less, or only quit after you guaranteed you learnt x skill you wanted from that project
joranstark018@reddit
I usually write small POC:s when I'm learning new things, just so I can focus on the interesting parts (ie. I may mock or use fake data, store data in memory, just to take the persistence layer out of the equation). I try different solutions and I try to gather information about the pros and cons of each of them.
samanime@reddit
At the end of the day, it doesn't matter.
A big project is just a ton of small projects in a trenchcoat.
Either method will probably produce similar results, especially early on. The important thing is simply that you are writing code and solving problems. What code and what problems is of significantly less importance.
Do whatever is interesting and motivating to you personally.