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.
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.
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.
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.
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".
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 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.
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.
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.
Your plan should include time spent on fixing bugs and addressing technical debt.