Reduce what you are trying to build as much as possible. Then reduce how much code you use to build it. Build something you can use as soon as you can. If you're writing a ton of code before this thing is getting used then how do you know that you actually need all that code?

Your plan should include time spent on fixing bugs and addressing technical debt.

I started a new passion project last year. I don't know if it counts as a huge project, but I could tell going in that it would be the largest and most ambitious solo project I've ever taken on. Given that this is a project that nobody is paying me for, I have the luxury of not having to give any deadlines, so depending on your situation, your mileage may vary.

Firstly, whenever I encounter a bug or an idea that I don't want to interrupt my flow, I make a note of it. I'm currently using a Github project board for this. You don't have to use any complicated features to do this, it can be essentially used as a todo list so that you keep track of the things you want to implement. These things should be broken down into small achievable tasks.

I have embraced the idea that this project might take me literally years to finish, or it might never truly be finished. There are a great number of successful software projects that are never finished! Linux, for instance! I've given myself the odd fleeting thought to how much time it would take for a v1.0.0, but never tried to calculate it. I've accepted that it'll be done when it's done. Especially given that I don't know if I'll be too busy to work on it in a few weeks time.

This way, by not worrying about when it'll be done, I'm finding myself in that flow state of just working on the thing that I want to work on right now.

I was once at a coding conference (Prograph CPX now you ask) and there was a coding competition. Who could create a usable To Do List App in one hour. About six people took part.

At the end of the hour, people demoed their creations. "This one is clunky and works like this...", "This one uses text to" etc.

The last person got up and showed some doodles and notes on sheets of paper. He said "Mine is the only one that actually works and is well designed, I just need to code it now".

I don't know if there's a lesson in there, but to me it was cool as.

I focus on today.

Throughout my career the backlogs have always feel infinite, the priorities high, the scope growing, the deadlines are impossible, and the stakeholders are always in a hurry.

It's not you, the company, or the project, it's just how the industry works.

You have to break it up. Chunks milestones and evaluation.

That is Chunk up the work over some periods

Milestones tell you when you want what. This helps with expectation setting and managing anxiousness.

Evaluation is seeing how you are going and what change needs to be made.

When I do my own projects it’s feature based one at a time but knowing what the full thing is in terms of vision. It doesn’t always go to plan.

For teams, agile design, agile thinking, delivery and monitoring. It doesn’t always go to plan.

When it didn’t go to plan the question is how do I respond to it. That’s where growth lies

Work as a team. Your team takes the weight equally, helps each other out, so on no day shpuld you alone work late (and working together late should be rate).

Also know this: it ain't your code. You can be fired at any time. Each day you work and you get paid. Not worth stressing. Instead make sure about staying employable and keeping up with interviews and networking etc.

I totally get where you’re coming from. One thing that has helped me is not just counting lines of code, but also using tools like Cursor (YC-backed) to get a sense of how my productivity stacks up against other developers. It’s a neat way to avoid the “just ship more code” mindset and focus more on efficient problem-solving.

I also find it useful to break projects into smaller, well-defined milestones. Instead of just aiming for a certain line count, I set targets like “implement the first API endpoint” or “get the first integration test passing”. This way, you’re not just pushing code but actually moving the project toward completion in a more structured way.

Curious if anyone else has tried using tools like Cursor or something similar for this?

What you describe is a form of anxiety. The behaviors and the problem is the same whether you are talking about code or a mountain of dirt. You need to address that directly without medication. The healthy way most people solve for this is by embracing stress, often not by choice, adversity.

As far as your large project just take it a step at a time. Have something to execute, then write your first feature or solution, then add some usability, then do type checking or linting or whatever, then refactor as necessary, then determine if that first feature should be expanded or if you need a second feature, then, then, then…

I create a project plan. What are the functional requirements for an MVP and work backwards until I can get task that can be done in no more than a couple of days. If it’s a solely project, I break down only the work for the current “epic” or “work stream”.

My current job (consulting) has me going back and forth between requirements gathering and proposal writing, tech lead/some project management and hands on implementations for smaller projects that don’t require a team. I have some project management training - just enough to be effective.

I don’t even think about lines of code. I think in terms of task completion.

For personal projects and even to juggle multiple projects at work I have personal Trello boards

Don't know about "ideal" but YC have a video where Michael Siebel talks about the dev cycle they had at Twitch. Before they applied it, he says, they wrote lots of redundant code and also get stuck on stuff that didn't matter.

Eventually, what they did was set up two-week dev cycles. Before each, they'd write down suggestions for features/WIP and stick everything on the board. They would also estimate if a feature was large (one week of work or over), medium (2-3 days) or small (up to a day). Then, they'd pick the most urgent things off that list, and work only on them. Two weeks later, same thing. But you don't keep a list of the ideas, the other things don't go into a queue.

I applied this for a product I was building last year, and it definitely helped build faster.

Not sure about measuring things in LOC or commits.