How Not to Be Overwhelmed | Hacker News Reader

How Not to Be Overwhelmed

11 pointsbanrovegrie15 comments

When starting a huge project or product from scratch how do you guys prevent yourselves from getting overwhelmed by the sheer amount of code to write or work to do?

I have a bad habit of trying to deal with this by estimating how much code I can write in a day and seeing how that compounds over time. That way when you see that you can have "x lines of code" written by the end of 2/3 months, it makes you feel okay this much amount of code is enough to finish up the project.

Not sure if this is the ideal way to go about things.

View on HN

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.

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 also started one of these several years ago and I have only implemented about half of the features on my todo list so far.

But I have many features working and each one feels like a victory when it gets working properly. Each time I find a few hours to work on it, I pick a task that I think I can complete within a day or two.

It feels like trying to climb a big mountain. You don't keep looking at the summit and feel overwhelmed because it seems so far away. Instead you look at the next milestone, which may be a rock just a few hundred feet away. When you reach it, you take a deep breath and pick the next target to work towards.

I love that! Climbing a mountain would be such an arduous task, impossible even! But taking another small step can be fun and easy. Keep having fun, and if you find yourself at the very top, look for another mountain.

Yep that makes a lot of sense.

As long as I can see the parts working, the endeavour feels fun and gradually everything starts looking better - as the product gets "denser".

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.

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.

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

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?

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

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?

"What's the simplest thing that could possibly work?"

You may need clustered databases with failover. First you have to get enough users for it to matter. So don't start with that. Start with a simple, single database. Yeah, think about the future - pick a database where you can move it to clustered - but don't plan out every detail of how you're going to get there. You don't need it now, and you may never need it.

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…

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.

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

Reply on news.ycombinator.com