Starting a personal project is a cool thing to do, but there are a lot of factors that can distract you from finishing your project. I collected 7 tips from my personal experience and I hope you can learn 📘 from my mistakes.
Choose a project idea that you are passionate about
No matter what you like more 🐈 or 🐕, reading 📚 or watching 🎥 - you should choose a project based on your personal preferences. For example, I like to 🧑🍳 in my free time for myself and my wife. So I decided to build a recipe app, where I can upload different recipes, search for them and view a very detailed process on how to prepare them. Your tastes might be different. You may want to build your To-Do app or a URL Shortener. But usually, the best ideas will come if you find yourself in a position where you are missing particular functionality from existing tools. In this case, you could end up building a project that many people will find usable and potentially you can build your own company out of it (you never know!).
Don't follow blindly tutorials on the Internet
The worst thing you can do when working on a personal project is to copy things blindly from the 🌐. There are tons of different tutorials for all different kinds of apps that you can build. While I am not saying they are useless, not at all you can learn a lot from how people approach different projects and use different strategies to build them. You can borrow ideas from those projects and I don't find a bit of copy/pasting evil, but you should never just write down the same code as the project author and call it a day. Instead, you should take your time and architect your project. In this process, you can pick a few pieces from different sources, but you should always understand what you are doing. In this way, you learn the most as you will tackle different challenging issues, that you will have to find the solution for. And overcoming those challenges is exactly what programming is about🚀
Set small reachable goals
Setting small goals is the best way to let you enjoy the process constantly. When you set goals for yourself and can reach them in a couple of hours ⏲️, you have a very rewarding experience. For example, you want to build a blog. You start by doing your research and deciding what set of tools you will use and that is your very first goal accomplished. Next, you look into how other people design their websites and you sketch a draft either on paper or a tool like Figma and this is already your second deliverable. When you work on the page each separate page and functionality like a button is a separate deliverable. In this way, you always have these small things that you can add and improve your website. Ideally, you should set up a light tracking tool like Trello or even a simple notebook. Just assigning a task to yourself and moving it to done feels very satisfying (trust me on that!). And if you want to get to the project after some time you can rewind the decisions you did and understand your motivation at that time. You will forget all the details about your project in just a few weeks.
Best practices are good, but you probably won't need them
It is always nice to learn and follow the best practices from the community like proper folder structure for your project, following all the naming conventions and extracting the interface for the class. But most of them are useful only, when you are working on a big team or you have a huge project. So instead of immediately going to a popular repository and copying their structure, you should aim for starting things simple and improving/changing the structure naturally as your project grows.
In my experience, in my recipe book Angular app I used a Redux-like state management library called NgRX. While it is a cool library and brings benefits for bigger projects, in my small project it only complicated things as after just a few weeks I couldn't remember how exactly everything was wired up and what I have to do to add some extra data to the state. If I would go with a simpler approach first (like using built-in services in my Angular app) I wouldn't have had those issues. And if I would later observe that this doesn't fit my use case anymore, it would be easier for me to switch to a more sophisticated solution than doing it in a reverse direction.
Stick to the tools you chose in the beginning
This is true for any programming language, but especially, if you are a JS developer as you can see a new framework/library being born 👶 every day. But before you jump on the hype train, ask yourself some of the following questions:
- Why did you start doing your project with the current tools?
- Were you trying to get some experience in them before you can apply for work 💼? If the answer is yes, then will this new shiny tool help you to achieve that? The answer here is usually no. As ✨ new tools are rarely used in the industry, they need to pass the test of time and be polished so they don't have any surprises, which you might also encounter and get stuck.
- Is there any real functionality that you are missing with the current tools and there is no way to easily replicate it or is it just the new tool is looking nicer or advertised as faster?
After you answered all the above-listed questions and you still feel the need to switch then fair enough - just do it! But, likely, that this won't be the case for you. Anyways, it is a cool idea to later re-write your project with a new tech stack or new programming language, but only after you have achieved at least your Minimal Viable Product state.
Decide what would be your Minimal Viable Product
Put the most necessary things and deliver your project as an MVP 🚀. MVP will ensure you stay laser focused and have a small deliverable that is usable and that you can even showcase. It should contain only a minimal set of functionality that you need to implement. Say you want to build a To-Do app. Functionality that can go in your To-Do app is creating new notes 📓, editing/deleting current notes and maybe moving the notes around. But then things like including a fully featured rich text editor, marking favourite notes or even creating folders are all extra things that go on top. They are not necessary for the MVP. Creating an MVP is all about building this solid foundation, making quickly something that is not very sophisticated, but supports the very core functionality that users would expect from your app.
Share your project with others
Once you build an MVP, it is time to share 📤 your project with the world. Nowadays it is super easy to do. First of all, make your project repository open on platforms like GitHub or GitLab. Next, you can create a small blog post about your project and post it on one of the awesome websites like Medium, Hashnode
or Dev.to. Last, but not least share it on any social media like Twitter, LinkedIn or even YouTube with your friends and followers.
You should not fear sharing your work, nobody will punish you for not providing the best solution possible, instead sharing your project helps you to get feedback from other developers like yourself. They can give you 💎 advices on your project structure, provide fresh ideas to work on or even find a bug that you didn't notice.
Thanks for reading my very first blog post! I hope you learned something new 😊 Feel free to drop links to your projects under this post. I will happy to take a look and give my feedback.
Top comments (15)
This might be for the people even less experienced..
Write trash code. Kludge together a monstrosity. Copy paste at whim and will.
Take the bush mechanic approach and try and put together anything and everything until it works. Or even better until it doesn't work. Then bash your head against a search engine working out why it didn't.
To put it less eloquently.. fuck around and find out
I agree on that, sometime I call them "explorations" because we are like just playing around, figuring out the use cases. But once we solve it or next time we face something similar at works will write more eloquent.
This is what I do. Then when I come to the end of it I analyse why my code is so crap, so I know how to write clean code.
One of my projects had a 200 line useEffect in :O
100% Agree, I changed my personal projects board last column to "iteration done" instead of done. New statuses are: idea, ready, in progress, iteration done. This helped me a lot to keep focus on one thing at a time and to scope out things for next iterations if they might happen.
@juanvegadev Yeah this is a very good advice. I use to keep my board in a similar fashion, but I additionally distinguish between Things To Do and Future Ideas. This way I don't forget about some crazy ideas, when they pop up in my head, but I also don't break my current workflow.
Same for me!
ready = thigs to do
idea = I just have this random thought, let's note it
I agree with your opinion
Set small reachable goals. A few months ago, I got intrested ingo. Before starting a create an app, I thought I needed to learn aboutgowell like how to make test code, etc. Still now, I haven't started to create an app yet. By having busy time at work, I alomost forgotgoI learned before. Thanks for your article. I'll start from a small project!Thank you for sharing your tips, the one that stood out for me was setting small Goals, that is very important because looking at a big project can be quite daunting, but having small goals each step of the way is so helpful on the long run
Thank you for this gem, Really! It helped me calm down pressure I can put on my self to look ridiculous with code some would find so beginner 🤣. But hey, everyone started somewhere and helping each other is the way to progress personally and collectively 👍
Happy to hear that you find this article useful. 😊
In software engineering no matter how much experience you have, you will always find topics where you are a complete beginner. From one side it is not easy to accept, but on the other side that is actually the best part of it. There is so much to learn and explore. Just enjoy the journey!
Useful tips. I will follow them with the project I am working on.
Very helpful!
Thank you @dhruvjoshi9!
Sometimes this works and sometimes it doesn't. Some devs write libraries/frameworks with a ton of reflection and abstraction which makes it nearly impossible to do anything the normal way.
NextJS is a perfect example.
@wadecodez I totally agree. There should always be a balance between the apporaches. I just wanted to point that, if you are working on a personal project most of the time you should just follow YAGNI and don't overcomplicate things unnecessarily.