You just finished another tutorial and have decided to try to build something of your own. You get an idea you’re excited about and want to jump in and start building right away! It might feel productive and energizing at first, until soon you start hitting blocks of things that maybe you didn’t think through well enough, or possibly at all. Is this even possible? Did i just spend two weeks on a feature I don’t actually need? Should I just start this over? --- Sound familiar?
When you are learning and building a side project, often one of the first mistakes made is not creating a plan and a process for building the project. One of the first things that may cause your project to go into a pile of abandoned GitHub repos, is if you get an idea and then you don’t limit the scope of that idea to an MVP (Minimum Viable Product). To get a clear idea of what you want to build you need to think through a few major things. I suggest using the questions below to write up a quick project spec.
MVP
- Description: What does your product do? What is its main purpose/function?
- Features: What are the bare minimum features you need to build it?
- Go through these features and ask again if they’re really necessary for your first iteration of something you can call finished.
- Architecture: What will your front-end and backend architecture look like?
- What frameworks/tools do you want to use? Are you using these because you want to learn them? Because they are the only things you know? Because they are the best choices for the project at hand?
- Do you need a backend? Will you be persisting data? how? Will you have a user system? And is it necessary for an MVP? What will your data models look like? What API endpoints do you need? Are you integrating data from third party APIs?
- Design: What views/routes will you have and a very simple design mock/wireframe of each so you have a visual idea of the structure of your application.
Workflow/Process:
Create broad milestone goals for your MVP features
- Create or find a project skeleton with the frameworks/tooling you have chosen
- Model your data/ create API’s / backend
- Front-end that consumes your data
- Design
Start breaking down goals into smaller problems, and begin to write up issues/tickets. You can group these on a kanban board such as on GitHub projects, a trello board etc.
Work as though someone else might join you at any time and will need to be walked through your codebase/process.
For me this meant using the idea of feature branches that corresponded to tickets which looked something like this: Create a feature branch, work on the feature or bug, push it up to GitHub and create a PR(pull request) to get my code reviewed before merging.
Sometimes seeing your code in a different format (i.e. not in your favorite code editor/IDE), but in a PR will be enough to make your brain catch something you might not have, or hold you to maintain a better standard of code quality and readability. If you are working alone, ask yourself would I submit this code for someone else to review/understand/merge?
Create a README file. Document how to get your environment set up in development. Even if no one else ends up working on your project, your future self will thank you. Document things in general.
If you have any feedback or comments about your own processes, or lessons learned, I would love to hear them!
Top comments (13)
Nice timing. I think planning projects are important too. Not to go crazy and create a 9000 page plan, but basically everything you wrote. It usually takes me around an hour or 2 for a decently sized project.
If you want to see an example of how I do this, I put up a time stamped 90 minute video doing this for a real new project I started a few days ago: nickjanetakis.com/blog/live-demo-o...
Yes, also having things written out helps you free up more brain power for making progress, or makes it more obvious why you may want to change your plan!
Yeah, that exact concept is covered in the video. It's just like coding where getting it out and working is step 1. Then you can sit back and make it nice afterwards, and that almost feels like a reward because you got the hard part done already.
Nice article! 💪👍
Planning your project before starting to code is so important.
Setting up a kanban board and working with it is something, that helped me a lot while working on a project.
I like the idea to ask yourself the question if someone would "review/understand/merge" your code if you would submit it for someone else.
This approach along with using a different editor to review your own code lets you see your work in a different light and may show you some mistakes.
I will try this approach in the future for my projects.
Maybe you want to read my article about my process of creating a web application. 😋
I used some of the tips for working on my project too.
Thank you! Its always important to remember that things can be broken down into smaller problems until you can solve them.
I have been stuck at this phase for sometime now, thanks for sharing this. Seeing some nice comments too.
Glad you found it useful! If you have any questions, let me know and i can see if i can help : )
Awesome article :)
Thanks for this article. I am looking for something like this so that I am create a project "plan" template for each project I work on. I want to put it into Trello to get more organized. Thanks
Great tips! It's so easy to fall into the trap of starting to code right away without proper planning!
thanks for this, it's quite helpful to get this much insight in a blog post. I'll be using this to help keep focus on my projects.
Thank you for sharing this! I love that you kept it relatively short - for me, this makes it a little bit less daunting and overwhelming to get started! :)
Amazing article. Essentially it’s a production style workflow. Thank you for this!