Clearly state what the application is going to do. You'll do this at all levels. Starting from a one liner and getting down to any level of detail. This will help you understand the different things you will need to provide (not only code). And most importantly you will understand better what are the limits of your application, what you don't want just now or never to belong to it.
Designing the architecture of your project is the first and most important programming task. A first approach could be this:
-
Study your specs.
- Underline specific nouns in blue. They are probably your classes/objects/properties.
- Underline specific verbs in red. They are probably your main methods.
- Underline specific adjectives in green. They are probably your constraints.
-
Write each identified word in its own box (post-it).
-
Move those boxes around on a dashboard.
- Related boxes should stay close to each other.
- Draw lines between boxes to see relationships.
- Add notes (stapled post-its) to the boxes.
-
At some point you'll realize that you need a new set of boxes.
- Draw them while looking at those on the dashboard.
- Add properties to boxes stapled to where they belong.
- Take a picture of the dashboard.
- Remove the old boxes and store them in a bag, just in case.
-
Repeat from 3 until you like what you have on the dashboard.
At the start, use generators to create a basic frontend app and / or a basic backend app. Try them out. Then, at any other iteration, right before changing anything, remember to make sure your code is still working.
As soon as your code is good enough, commit it with a good message. Whenever you feel the feature you are developing is going to require more than a single commit to get to a new good enough point, work on a separate branch, so that, at any other time, you or your team mates can continue working on a good enough code base.
That's all folks. Now it's only a matter of repeating the above process once and again, possibly forever. :D