Developer Workflow

Why workflow matters

Good developers manage complexity. A strong workflow prevents messy files, unclear names, duplicated code, broken links, and slow debugging.

File organisation

Static websites commonly use folders for assets, css, js, and pages. File names should be lowercase, descriptive, and consistent.

Naming conventions

Class names should describe purpose rather than appearance. course-card is stronger than blue-box because the same card might not always be blue.

Browser DevTools

DevTools let you inspect HTML, test CSS changes, view console errors, monitor network requests, and debug JavaScript. Use the Elements panel to identify layout rules, the Console to follow runtime failures, and the Network panel to find missing files or slow assets.

Debugging methodically

Start by reproducing the problem reliably. Write down the expected behaviour and the actual behaviour. Then narrow the possible cause: inspect the relevant element, read the console, check the loaded files, and change one thing at a time. A small testable hypothesis is more useful than random edits.

Refactoring

Refactoring improves code structure without changing behaviour. It includes removing duplication, renaming unclear classes, and extracting reusable functions. Refactor after the current behaviour works and verify that the user-facing workflow still behaves the same.

Example code

project-folder/
  index.html
  assets/
    logo.svg
  css/
    styles.css
  js/
    main.js

/* Purpose-based class names */
.course-card {}
.site-header {}
.primary-button {}

function toggleMobileMenu() {}
function validateEmailAddress(email) {}

Applied example: write a useful bug report

A clear report gives another developer enough information to reproduce and verify the issue.

Issue: Mobile menu does not close after selecting a link

Steps:
1. Open the homepage at 390px width
2. Select Menu
3. Select the Contact link

Expected: The page navigates and the menu closes
Actual: The page navigates but the open menu covers the content

Console: No JavaScript errors

Guided example: how to approach this lesson

Use these steps as a practical build process. The goal is not just to read the concept, but to know exactly how to apply it in your own page.

Step 1: Create the folder structure

Before coding, create folders for assets, css, js, and pages. This keeps the project easy to navigate.

Step 2: Build in small steps

Write a section, test it, then continue. Avoid changing many unrelated things at once.

Step 3: Use DevTools constantly

Inspect layout, test CSS edits, read console errors, and check network files while developing.

More examples

Compare these examples carefully. The improved version shows the kind of code pattern you should aim for when building your own project.

Messy project

website/
  index-final-new.html
  style2.css
  logo copy.svg
  script latest.js

This is difficult to maintain because file names are inconsistent and unclear.

Organised project

website/
  index.html
  assets/
    logo.svg
  css/
    styles.css
  js/
    main.js
  lessons/
    html-foundations.html

This structure is predictable and easier to scale.

Before moving on

Use this checklist to make sure you understand the lesson well enough to apply it without copying blindly.

Are file names lowercase and descriptive?
Are CSS and JavaScript in separate files?
Have you checked the console for errors?
Can another person understand the project structure?

Common mistakes to avoid

Putting all files in one folder.
Ignoring console errors.
Changing many things at once while debugging.
Using class names based only on colours.

Practice task

Turn your homepage exercise into a maintainable small project and run a focused debugging pass.

Required outcome

Organise the project into clear HTML, CSS, JavaScript, and asset locations with descriptive lowercase file names.
Inspect the page with DevTools and confirm there are no console errors or missing assets.
Find one visual or interaction issue, record reproduction steps, and fix it with a focused change.
Review your class and function names so they describe purpose rather than appearance.

Stretch goal: Write a short release checklist that another learner could follow before publishing the project.

Previous lesson Next lesson

What you’ll learn

Track this lesson