A mistake I made a lot during my university years: Starting a project without a plan, continuing it, then quitting and starting another project after a while because I couldn't cope.
I explained the detail of the flow I made in the image step-by-step below, I hope it will be useful ⚡️
Finding Ideas
- You should do a brainstorming for this. It may also be useful for you to visit sites such as Producthunt and betalist and examine what the world is doing.
Planning
- The most important stage. Here you need to do a detailed planning. Which technology will be used, how much time will be allocated, what will be the size of the project, budget allocated etc etc. When this stage is over, you can clearly understand whether you will continue the project or not.
Start Project
- Don't believe too much in the saying "starting a project is half the finish" and believing that the main thing is to start. The main thing is to keep the project going.
Development
- If you have done the planning properly, you will now only have the workload of coding. You will apply the roadmap you drew during the planning phase step by step.
Publish
- Congratulations, your project is complete. You can now go to Production and share this project in places such as Product Hunt, Twitter, LinkedIn, Instagram ... and watch the incoming interactions.
Top comments (18)
Strongly disagree. The most fun projects where you learn the most are the ones with a vague idea, and you just jump in and start playing. I've found that the best stuff always starts out this way.
If something good starts to form, then maybe take a step back and start formalising things a bit.
Also, not everything has to be a product - or even have a well defined purpose. Why treat projects that way? Why not just play with code like playing with Lego? It's enjoyable in itself, improves your skills, and can lead to awesome projects.
I respect your opinions, but as a backend developer, I don't want to CRUD every time and move on to another project. I believe that after developing the basic parts such as CRUD, completing the DevOps process on platforms such as AWS, Google Cloud and finishing a project as E2E brings much more experience.
I'm just a developer. Built all kinds of stuff - desktop apps, backend systems, frontend stuff, games, graphics drivers, whatever takes my fancy. I guess most of my projects tend to not be particularly 'conventional'... I just make whatever I want, however I want.
I save the more 'ordinary' stuff for doing as 'work' to pay the bills, but even then I try and seek out work that's more interesting and unusual.
I guess I've always viewed programming as more art than science or engineering... hence the way I prefer to approach projects.
So I can only partially agree with you.
Understanding, of course, that there are different reasons for each approach.
From our perspective as devs, we want to learn more and understand what we didn't understand yesterday. So for that purpose, you're jumping right in is exactly what many of use would do.
However, if you're in a business project that you're being paid to do, it is a disservice to the client to not have planned and documented and be as prepared as humanly possible ahead of time. It's just a must for a very different reason.
Otherwise, just dive right in! ;P
The OP is talking about personal projects it seems.
Understood but the variety of response is due to different context, which was my point for clarifying, because some will be militant about it lol and context is really the reasoning one way or the other ;)
People thinking like you always fail.
How kind. Thank you so much
I am not kind. I am respectfully realistic. 😎☕.
If you do not plan your works, you always fail. This is the simple quote of life bro, 👍
I never said don't plan, but making too rigid a plan up front is very often a mistake. Playing with and refining ideas first very often leads to much better results. Planning too early can lock you into a path that may well be the wrong one. My advice comes from almost 4 decades of programming experience - it may not work for everyone but it certainly works for me.
That is why there is methods of planning. Example if you want to prototype an idea quickly, you can use agile dev. You see there's always a solution bro.
As I said - whatever works for you. I've tried Agile too - too many meetings, too much ceremony.
1 per week is good I suppose. We are thinking the same way. I don't idolize the agile or planning and in the thinking way, you are right. Because before 2 comments before you said, I never said don't plan, so I am saying there must be a plan.
Think it like a chess game. There is a planner. But the pawn or even the queen does not plan the game. The queen does what it can. So in the team of a project there must be a planner. Chess game, soccer or anything. If you do alone, you can plan but this will slow you. So you must be Very careful about not planning too much. That why experienced people is more successful vs not experienced.
I think that depends on the project, purpose of it and experience.
If it is not big, with experience how things usually works, you can make something working fine enough.
If this is project for learning it is even better to start right away to make more mistakes to learn from.
Flow which you proposed is very valuable if you want to have something which require much more time and potentially could be used by other people.
Thank you, dude. I will start new project on next week
good points you raised here, nice
Totally agree ! I started doing that two years ago, and since I am following this workflow, I ended up developing more projects, published and usable.
I have vast experience with the 1st method. It is working!