A mistake I made a lot during my university years: Starting a project without a plan, continuing it, then quitting and starting another project aft...
For further actions, you may consider blocking this person and/or reporting abuse
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 ;)
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.
good points you raised here, nice
Thank you, dude. I will start new project on next week
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!