Hello there!
This post here is to go through (with you) my thought process when trying to create and release a side-project idea. It's r...
For further actions, you may consider blocking this person and/or reporting abuse
Wow! Realy nice post. When we stay alone with a Idea or new solution, do organize all aspects could be creppy on start. You explained all basic steps pretty fine.
Could you consider a sugestion about your next post? How do work with a partner on this same project, sharing doubts and code.
Bye!
Thanks for the comment and the suggestion! I really liked it!
I'll surely write about it, I was already working on something similar to this, so it should come in a near future! 👍
If you have any other suggestions of moments on the developer life that you struggle with, don't hesitate to tell me. I'll write my thoughts on it as soon as possible.
Hey @robsongrangeiro, I made an article about communication that I think you should check out! It can give you some insights on the process of working with partners and other people in general! Have a good read😀
This is a great article. You showed us your thought process, which is thorough.
It's true that some developers never get their idea out of paper. I was like that before, but now, I'm trying to get out an MVP for feedback and suggestions. The processes you listed in this article will help.
thanks for sharing.
Thanks for the comment and the good feedback!
It's really good to see that you're trying to get feedback for your MVP and that the article will help you on it. It's easy for us to completely ignore the users in the creation process, leading to a product which the users don't need.
The users, which are the target public you want, are the central piece of it all. We should never forget that.
Thanks again!
Yes, the users are the main component in the success of any product.
If users don't like the product, the product is a failure, no matter how you paint it.
You have code way too late in the process for my taste. In my opinion you should start coding at step one and again at every step. Your planning and refinement will mean little until you start to flesh out your project.
Thanks for the comment!
Well, in minor side-projects, I agree with you that maybe we can pull up the code phase in the step list, but, if you're going to do something a little bit more than minor, I usually like the approach of thinking first - coding later better, since it can prevent a lot of refactor later.
The general idea is that, if you spend time thinking about it before coding, you'll only have to code the basis of the architecture once and it will naturally evolve and develop itself without a lot of hassle. When you don't spend the necessary time thinking, you generally solve the problems as they come (which can be unoptimal and even more problematic later, since quick solutions can generate even greater problems).
But you're not alone on you opinion too, a good strategy if you have more eagerness to code and don't care to refactor some of it later (while still maintaining the certainty that your code works as expected) is start by developing some tests! TDD can help you a lot in those cases 👍
This is an article I never knew I ever needed so badly. I currently have some side projects but I never knew how to plan them out and implement them like some software engineering project. Your article gave me a lot of insights on how one can approach a project and just start building.
Thank you so much!
Thank you!
My question, as a beginner, would be: after you have the idea, between steps 1 and 2 (or 2 and 3), how do you evaluate the feasibility of completing what you first envisioned? Experience/knowledge? Or do you go over that during the 'planning' phase?
Excelent question! The feasibility of a project is majorly dependent on the experience/knowledge of the team working on said project and should be planned accordingly.
One way of resolving this is simply evaluating in terms of hours of development every feature drawn on the plan.
Your first evaluation probably will not be really precise (and you can ask other developers to evaluate this set of features aswell). But, do not worry! You'll get better at it!
At the end, the feasibility of a project will be a simple matter of answering the question: Do I have enough time to complete every feature? If not, what should I prioritize in order to create enough of a product that will still generate value for our users?
Great article! I often see some developers neglect the planning and refinement phases, which I agree are big mistakes.
One 'hot take' that I have (honestly, I don't know if it is still a hot take) is that planning too much at the lower levels, like the code itself, is not worth it.
I don't mean people shouldn't think about code architecture and design patterns, but designing the entire system with UML and then starting to code is, in my opinion, a waste of time. It's sort of like learning programming fundamentals with pseudocode and then learning an actual language – you can do both at the same time.
Great article - broken down the steps really well. This is very similar to how I would go about it but instead I prefer to do a bit more validation first before I start coding.
Thanks for comment!
The larger your project/idea becomes, more validation is needed before coding (and in general, is better to spend more time validating, than discovering that you coded something useless or bad architectured). Nice tip!
Exactly!
It's so important to do this before you start writing code, otherwise you have no idea if the things your building are actually want your customers actually need.
Plus having a bunch of features from day one can make it much harder to figure out whats working and whats not.
This is comprehensive, and I loved reading along with you through this marvelous journey you shared with us.
Thank you!
It's great to read that you enjoyed reading as much as I enjoyed writing it!
Thanks for the reply!
Amazing article! The step by step guide with resource links and your own project as the case study with screenshots is high quality stuff!
Thanks a lot for the comment! I hope that part of my journey and the findings that I learned can be inspiring for you!
This was a grand article, thank you for sharing what you have learnt, providing resources and the real-life example.
Thanks for all the references to valuable tools in dev process! 👍