DEV Community ๐Ÿ‘ฉโ€๐Ÿ’ป๐Ÿ‘จโ€๐Ÿ’ป

DEV Community ๐Ÿ‘ฉโ€๐Ÿ’ป๐Ÿ‘จโ€๐Ÿ’ป is a community of 966,155 amazing developers

We're a place where coders share, stay up-to-date and grow their careers.

Create account Log in
Max Dev
Max Dev

Posted on

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, 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 (16)

Collapse
 
poisonintheink profile image
poisonintheink

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

Collapse
 
allobrox profile image
Tamas Rigoczki

If something is stupid but works, it ain't stupid ๐Ÿ˜†

Collapse
 
jesusantguerrero profile image
Jesus Guerrero

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.

Collapse
 
jackmcbride98 profile image
Jack McBride

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

Collapse
 
juanvegadev profile image
Juan Vega

Set small reachable goals

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.

Collapse
 
maxr96 profile image
Max Dev Author

@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.

Collapse
 
juanvegadev profile image
Juan Vega

Same for me!

ready = thigs to do
idea = I just have this random thought, let's note it

Collapse
 
lico profile image
SeongKuk Han

I agree with your opinion Set small reachable goals. A few months ago, I got intrested in go. Before starting a create an app, I thought I needed to learn about go well 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 forgot go I learned before. Thanks for your article. I'll start from a small project!

Collapse
 
danvin001 profile image
Dan Vin

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 ๐Ÿ‘

Collapse
 
maxr96 profile image
Max Dev Author

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!

Collapse
 
kansoldev profile image
Yahaya Oyinkansola

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

Collapse
 
vishwastyagi profile image
Vishwas Tyagi

Useful tips. I will follow them with the project I am working on.

Collapse
 
dhruvjoshi9 profile image
Dhruv Joshi

Very helpful!

Collapse
 
maxr96 profile image
Max Dev Author

Thank you @dhruvjoshi9!

Collapse
 
wadecodez profile image
Wade Zimmerman

Best practices are good, but you probably won't need them

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.

Collapse
 
maxr96 profile image
Max Dev Author

@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.

๐Ÿ‘‹ Haven't Posted on DEV Yet?

Head over to our Welcome Thread and tell us a bit about yourself!