Abraham Lincoln is often quoted as saying, "Give me six hours to chop down a tree and I'll spend the first four hours sharpening the axe."
These words ring true as a principle for building larger, more complex projects. Every code review we assign requires many steps to complete. Some of those steps, although once foreign to you (Git flow, CSS, HTML, etc.), are now parts of your project that require very little additional learning to achieve.
That said, every Friday project also includes subject matters or objectives that are new. For instance, in every class you've learned ways to separate back-end and front-end code. while going through the content the first time, you may have asked "Which part of my app is front and back end?" "How do we remove our HTML from inside our API call?" "What do each of my dependencies achieve for me to this end?" These were all new concepts that require harder work to comprehend and implement than previous concepts.
So, with each new week, you have two options to tackle the task at hand:
If you think of your project like cutting down a tree, you could charge straight into it without any structured planning, starting with the easiest steps (HTML, CSS, etc.). Your work may be GREAT. In fact, you may get your proverbial 'axe' most of the way through the 'tree' before realizing that it's too dull to finish the job.
But you may end up with a commit history showing no clear direction. Your readme is written after the fact, so it can include a description and describe a little bit about the project, but you didn't use it as a helpful tool for development.
And, possibly most importantly, if an employer pulled up your work and asked you why you decided to develop the way you did, you would have no choice but to tell them: "Well... I didn't know how to tackle my API problem/gulpfile/npm dependencies... so I decided to leave that for last... oh and by doing so I coded myself into multiple corners... meaning I spent a huge part of my day fixing problems I created for myself instead of investing time at the beginning of the day on the problems I really should have spent my time on learning."
Abraham Lincoln wouldn't approve!
Instead, you could spend time in the morning intentionally not coding. You could ruminate on the problems at hand. Clear your mind of the stress of completing the project and write down a list of to-dos. Don't even organize them. Just let all the potential subdivisions of your code challenge come to you naturally.
Do you need a specific file structure? How many files? What kind of naming conventions? Which dependencies? Why? What kind of experience do you want for your user? What kind of style do you foresee integrating? Do you have a funny/engaging theme/name for you project that makes it more fun to use? What about deployment to Heroku? Is this a good use of time? What potential problems may arise with any of these tasks? Do you need to look back at the curriculum or read a little more about something before you feel comfortable adding it to your plan? What other steps can you think of?
Now go get a coffee, or eat breakfast. Just sit and do nothing for ten minutes. Then... only after giving your mind the necessary time to comprehend the scope of the project... organize your list into a structure that looks something like the example below. Include it in your readme. COMMIT YOUR README FIRST WITH ONLY A PLAN.
## Planning 1. Configuration/dependencies * This should include ALL dependencies. * It should also include WHERE they are defined and used in the project * It could include a short description of what each does for you 2. Specs * Spec 1: Description, input, output. * Spec 2: Description, input, output. 3. Integration * Initial routes or index pages with all dependencies in Controller/index.html head * Template/html page for ... * Template/html page for ... * Template/html page for ... (one for each route/integrated user story) * Display... * Integrate feature that... 4. UX/UI * Include and modify bootstrap/materialize/Sass etc. * Develop custom style 5. Polish * Refactor minor portion of... * Delete unused... * Make README awesome
Keep in mind while you're working, not all projects need extensive specs. Some projects need no specs. Does your project need specs? Make an informed decision about whether or not to include them! Include your reasoning in your plan.
So now you've just spent 15 minutes to 1 hour on no coding whatsoever. Instead you've sharpened your axe - getting ready to fell that tree in the fewest strokes possible. Abraham Lincoln would be VERY proud!
Once you reach the "Polish" phase (as outlined by the plan above) you have more work to do with your README. Is there a way for you to make your README easier to understand or more enjoyable to look at for perspective employers? Are you proud of how it exhibits your work? There are lots of resources to refer to about increasing the quality of your readmes. Here are a few that you should take a look at:
Eventually, when you graduate, you'll want to have a README for all projects. By including this in your workflow now, you'll avoid a huge pile of work later on.