The 3 principles of successfully starting and completing a web project

I am speaking from personal experience when I say sometimes personal projects can be overwhelming. You have an idea and can't stop thinking about it and it grows into a much more complex idea. You finally get the chance to sit down and code but your keyboard doesn't get much use since you are stuck on the age-old question: "Where do I start?". I recently went through this and ended up getting so overwhelmed with everything that needed to be done that I completely scrapped the project. As I look back on what went wrong or what I could have done better I can pinpoint 3 principles that could have helped keep me on track and make things a little less overwhelming. Timeline, Reason, and Procedure.

In this article, we will take a look at each one of these principles and how they can help you successfully start and complete a web project. While these principles alone won't take you over the finish line (you still need to build it) they should serve as a framework of sorts for how you approach starting a personal project.

Defining a Timeline

One area I think is the most important is establishing a timeline. When are you going to build this project? How long do you think it will take to complete? How much time can you devote to this project on a normal day? These are the questions you should be asking yourself. If you don't allow yourself enough time, the project won't seem to be making enough progress and you risk running out of steam and burning out.

Using a kanban-style board to break up your project into micro-tasks can be especially helpful when trying to visualize. If the service you are using to keep track of your project supports time estimates I would highly suggest taking advantage of that. You don't need to be 100% accurate and it's not a huge deal if you go over or under. What matters is that you can now visualize how much time you will need to complete x or y. Let's say you can devote 3 hours a day to this project, you can do three 1-hour tasks or one 3-hour task. Because you gave those time estimates you aren't going to need to worry about starting something you can't finish. If you have a few tasks that exceed what your normal time allotment is, consider breaking up that task into a few smaller tasks that are easier to manage.

Understanding the Reason

Why are you building this project? Are you trying to build a portfolio to get a new job? The reason needs to drive what you do. If you have a clear definition of why you are building the app, decisions can be influenced and will ultimately be easier to make. If you are building a portfolio in the hopes of landing a new job, then that reason should drive you to display some of your previous work on your site or have a link to your GitHub front and center.

I'm not a designer by any means and that is usually my biggest pain point when starting a new project. What should it look like? I usually will sketch out a mockup as I find that wireframe/mockup tools are a little out of my league when it comes to making something that looks pretty, whereas a simple rectangle with some squiggles on a piece of paper does the trick for me. When I get stuck with how it should look I look back as to why I am building this. Again, if you are looking for a job and building a new portfolio site, what do you think your "target audience" would want to see as the first thing? Some quick information about you with easy navigation to other areas of the website/social networks. All of my lapses in design can be filled in by understanding the reason behind the application.

Outlining your Procedure

When it comes to a new project it is helpful to know what you are building and how you are going to build it. What tech stack are you using? How will your users be able to utilize the main concept of your application? By outlining this you are going to be much more organized and your project boards will thank you.

I have started a project using a single tech stack, then migrated to another halfway through because I made the wrong decision. I spent a lot of time converting from one framework to another and that time could have been put towards active development instead. This is a costly mistake and once that can be prevented by having a clear procedure in place.

Another thing that can be difficult is knowing where to start. A phrase I often say to myself is "It all starts with a button". Meaning if you don't know where to start why don't you work on button styles? Let's say you have a sketch or a mockup available, scan through the page and make note of the different components/elements in use. You will most likely have a button or link that needs to have a consistent appearance. While you are more than welcome to start building any other component/element it can be handy to always have the same starting place.

Conclusion

All three of these principles should work together to help you achieve success. Defining a procedure will help you have an accurate timeline which will help keep your dev hours to a level compatible with your schedule. Understanding the reason behind your development will help inform the decisions you need to make for your procedure. I'm building this portfolio to get a job as a React dev, so I should build my portfolio in React. I wish you the best of luck in your endeavors and hope this article helps you succeed.

Happy Coding!