I used to abandon projects as soon as they basically worked, without investigating why they were slow, messy, or unreliable. Recently I started taking an iterative approach: building multiple versions of the same feature and comparing the trade-offs. That taught me a lot, especially while developing a comment section, but the process took about four months. I'm happy with what I learned, though I wonder whether that time would have been better spent building several different projects. How do you balance going deep on one project with exploring new technologies and problem types?
5 Answers
Spending four months on one project isn’t automatically too long if you were deliberately comparing implementations and learning from the trade-offs. It becomes less useful when you’re repeating the same tasks or polishing details without gaining new understanding. Set a learning goal for each phase, and when the project stops challenging you, move on or introduce a new technical constraint.
The strongest sign that you’re progressing is being able to come up with an idea and work out how to build it without following a tutorial step by step. Projects are useful because they force you to research, make decisions, debug, and adjust. Whether you stay with one project or switch between several matters less than whether you’re doing that problem-solving yourself.
The important thing is to keep pushing beyond your comfort zone. Staying with one project can be valuable, but if you always use the same stack, libraries, and patterns, your learning may slow down. You don’t have to start a completely new application every time—adding an unfamiliar feature or trying a different design can provide the same challenge while avoiding repetitive setup work.
A good approach is to break the large project into independent features. For example, build the basic page first, style it, add a form, display the submitted data, then connect it to storage and implement the rest of the CRUD operations. Smaller milestones make debugging much easier because you can isolate problems instead of searching through one huge application. They also give you useful checkpoints and portfolio updates.
I’d use a mixture of both. Keep working on the main project, but when you get stuck or start going in circles, spend some time on a small side project. Changing context can help you think about the original problem differently. You don’t necessarily need to abandon the main project; the smaller project can just be a way to experiment or reset your perspective.
That balance is probably what I’ve been missing. My main concern is fitting both approaches into limited time, but using short side experiments seems more realistic than starting another huge project.