Session 9: Planning & Structuring a Project

Every unfinished project was over-scoped at the start. 'A platform where anyone can do anything' is not a project; it is an aspiration, and it produces six weeks of half-built features and nothing published. The discipline is to write down the one thing the finished project does, in a sentence, and to cut everything that does not serve it.

Then separate must-have from nice-to-have, and build only the must-haves first. A useful way to think about it: if you had to publish in two weeks with what you have, what would you be ashamed was missing? That list is the must-haves. Everything else goes on a later list, which you may never reach — and that is fine, because a published small thing beats an unpublished large one every time.

The reason this matters so much is that motivation is finite and unfinished work is demoralising. A project you complete teaches you vastly more than one you abandon at seventy per cent, and the portfolio value of a live site is real while the value of a repository of half-built features is nil. Scope down until finishing is realistic, then finish.

A task you can complete is specific and small enough to finish in one sitting. 'Build the website' is not a task. 'Create the header markup with the logo and navigation' is. The difference is not pedantry — a vague task cannot be started, because there is no obvious first action, and it cannot be finished, because there is no clear end.

So write tasks as verbs with an object and a visible result: 'style the card grid', 'wire the contact form validation', 'add the mobile navigation toggle'. Each one is startable, completable, and lets you see progress, which is what keeps a project moving through the unglamorous middle.

Then order them by dependency and by risk. Do the uncertain things early — the part you are not sure how to build — because discovering in week three that your central idea does not work is far worse than discovering it in week one. And do the shared foundations first, since everything else sits on them.

A clear structure means you can find anything without searching, and anyone else can understand the project in a minute. The conventional layout for a small site is simple: `index.html` at the root, then `css/`, `js/`, `images/` (or `assets/` for all media), and any additional pages beside the index. That is genuinely enough for most projects, and elaborate structures for small sites create work rather than order.

Then the naming habits that save you later. Lowercase filenames with hyphens — `about-us.html`, `main.css` — because they are consistent across operating systems, never contain spaces that break in URLs, and are readable. `Final_v2_REAL_final.css` is what an unorganised project looks like in week four, and it happens to everyone who does not decide on a convention in week one.

And one file per concern. All your styles in one stylesheet, all your scripts in one or a few files grouped by purpose — not styles scattered across six files and inline in the HTML. A single place to look is what makes a project maintainable, and the moment you cannot remember which file something is in, the structure has failed.

Reuse is what separates writing a page from building a system. The habit is to notice repetition and extract it: the same card appearing six times is a pattern, and the same button style appearing everywhere belongs in one class. Write it once, use it many times, and change it in one place.

In plain HTML and CSS this means classes you apply repeatedly — `.card`, `.btn`, `.btn-primary` — and consistent naming so the classes describe what something is rather than how it currently looks. `.btn-primary` survives a colour change; `.green-button` becomes a lie the first time you restyle.

The same thinking applies to JavaScript: a function per repeated behaviour, taking the parts that vary as parameters. And the discipline behind all of it is not extracting too early — waiting until something is genuinely repeated twice or three times before generalising, because guessing at the reusable shape too soon produces abstractions that fit nothing properly.

Git records snapshots of your project so you can return to any of them, see what changed and when, and recover from mistakes. GitHub is a place to store those snapshots online, which gives you a backup, a shareable link, and the portfolio that employers actually look at. They are related but distinct: Git works entirely on your machine without GitHub.

The core workflow is four commands. `git init` starts a repository in your folder. `git add .` stages your changes. `git commit -m "message"` records them as a snapshot. `git push` sends them to GitHub. That loop, repeated, is most of everyday version control.

Then the habit that makes it valuable: commit often, with messages that say why. 'Fix header alignment on mobile' tells you something in three months; 'updates' tells you nothing. Commit after each working change rather than at the end of the day, because small commits are easy to understand and easy to undo, while one enormous commit is neither. And add a `.gitignore` for anything that should not be stored — build outputs, dependencies, and anything containing a password or API key, which once pushed is very hard to remove completely.