How do I choose a good project idea when I'm learning to code?

The best project idea is a small annoyance in your own life that software could fix. That criterion solves both of your problems at once: it's automatically original enough to be interesting, and it's usually small enough to finish. How to generate ideas that fit you: 1. Notice friction for a week. What do you track in a messy note? What do you calculate repeatedly? What information do you check across three different sites? Each one is a project. Examples people have actually built: a tool that tracks their gym sets, a page that shows their class timetable on one screen, a splitter for shared flat expenses, a search over their own notes. 2. Build a tool for a specific person. Your friend who runs a small shop, your college club, your parent's small business. Having one real user transforms the project — you get requirements, feedback, and a story to tell in interviews that no tutorial project can match. 3. Rebuild something you use, but only one feature of it. Not 'clone Instagram' — build just the image feed with likes. Scope is the skill you're practising. How to size it correctly, which is where most people go wrong: - Write the feature list, then cut it to a third. Whatever you think it will take, it'll take about three times longer. A project that takes two weekends is a project you'll finish; a project that takes three months is a project you'll abandon at 60%. - Define 'done' before you start, in one sentence. 'Done means I can add an expense, see the list, and see the total.' Everything else is a later version. - Make sure it has a small amount of every layer: some interface, some logic, some data storage. That's what makes it educational, rather than a styling exercise. The idea that's 'wildly beyond your ability' — keep it on a list. Not everything has to be built now, and in six months you'll be able to attempt the smaller version of it. The gap between 'too trivial' and 'too hard' narrows quickly as you build. And about to-do lists: building one is genuinely fine as a *first* project — it touches state, input, storage and rendering. The problem is only using it as a portfolio piece, because everyone has one. Build it to learn, then build something personal to show. One last filter that saves a lot of wasted effort: pick something you actually want to exist. Motivation carries you through the boring middle of a project, and 'I want to use this' is far more durable fuel than 'this would look good on my resume'.