7 Things to Consider When Working On a Personal Project

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, 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 😊