Overview

There are many great tutorials that walk you through creating apps, from simple todo lists to fully working web apps. But how do you start your own projects from scratch? Without the safety net of a tutorial, you might feel a bit lost on what to build, or even how to get started.

What you'll learn

Plan your features, win your future

A goal in this sense is basically what you want to achieve with your project. Once you've started your own project, it can often be difficult to know when to keep going, and when to stop and move onto the next one. If you start with a goal in mind, it will give you something to aim for

Communicate your plan

The goal is also your project plan that you should work on first. Let's create README.md and put your plan in. The section that describe your project feature commonly called User story. Example:

## User story:

- User see navigation bar and able to navigate to different sections and pages
- User see a list of products on landing page
- User click on product card to see product detail in another page
- User can add product to cart/favorite using logo button in product card
  ...
  ...

From here on out, in your GitHub projects, you should have a clean, consistent README.md file that is actually useful. Use this template for this, and all future homework assignments: CoderSchool Template.

You'll encounter problems you never knew existed

Often when you learn in the class, you are learning the happy path which means everything works at the first try. Unfortunately, the live of a developer is not as straighforward. When you are writing code, you will always hit issues at some point.

So don't be frustrated, let's encounter problems naturally and overcome them. Solving problem is what developers do everyday and practicing will make it a lot easier.

If you make 999 bugs, it does not mean that you have fail or bad at programming. It means that you have discovered 999 new ways your program could fail. Thus 999 less chance to crash your program.

Rubber duck debugging

Don't laugh, it is actually a widely and effective debugging method amongst developers. To rubber duck debug, you would explain your code, logic, and the bug to a toy - rubber - duck or any type of non-code object (table, pencil, chair, non-code-crush) Disclaimer: we do not take responsible if crush.exe not found or crush.exe has crashed

By explaining logic outloud to non-code audience, developer tend to see minnor detail that regularly missed because of tunnel vision when staring at code screen for too long.

Have fun!