🛠️ Weekend Project: Build Your Development Workspace

You've learned the pieces — editors, browser tools, project structure, Agile, and productivity systems. This weekend you'll assemble them into one deliberate workspace: the environment you'll live in for the rest of this course and beyond. It's a hands-on build, guided by a problem-solving framework you can reuse on every future project.

🎯 Learning Objectives

By the end of this project, you will have:

Configured a customized code editor with extensions, settings, and reusable snippets
Set up a browser development environment with the right extensions and DevTools tweaks
Created reusable project templates and a scaffolding script
Stood up a working task-management board for your own projects
Applied Polya's four-step framework to a real build and captured your setup in a repo

Estimated Time: 4–8 hours (a weekend, split across sessions) • Difficulty: Beginner–Intermediate

Hands-on: This entire lesson is the exercise — a guided build with milestones and a final checklist.

In This Project

What You're Building

A development workspace is more than an editor. It's the whole set of tools, templates, and habits that let you start a new project in minutes instead of an hour of fiddling. By the end of the weekend you'll have four connected pieces committed to a Git repository you can clone onto any machine.

flowchart TD A[Your Dev Workspace] --> B[1. Customized Editor] A --> C[2. Browser Dev Setup] A --> D[3. Project Templates] A --> E[4. Task Management] B --> B1[Extensions · Settings · Snippets] C --> C1[DevTools · Extensions · Bookmarks] D --> D1[Frontend / Backend / Full-stack + init script] E --> E1[Kanban board · labels · task template]

✅ Why this matters

Professionals invest in their tools once and reap the benefit on every project afterward. A tuned workspace removes friction so your energy goes to solving problems, not re-configuring your setup. Treat this as building your own workshop before the real carpentry begins.

Your Compass: Polya's Framework

You'll approach each milestone with George Polya's four-step problem-solving method. It was written for mathematics, but it fits software perfectly — and using it on this project builds a habit you'll rely on for every feature you ever ship.

flowchart LR A[1. Understand
the problem] --> B[2. Devise
a plan] B --> C[3. Carry out
the plan] C --> D[4. Look back] D -.->|next problem| A

Step	Ask yourself	For a developer
1. Understand	What exactly am I solving? Inputs, outputs, constraints?	Read requirements, restate the goal, sketch a test case.
2. Plan	What approaches exist? Can I break it into smaller parts?	Choose tools, outline architecture, list tasks in order.
3. Carry out	Am I following the plan and checking each step?	Implement piece by piece, commit in logical chunks.
4. Look back	Does it work? Can I simplify or reuse it?	Test, refactor, document, and note lessons learned.

💡 Use it out loud. At each milestone below, pause and jot a sentence for each Polya step before you dive in. Two minutes of "understand + plan" routinely saves an hour of "carry out the wrong thing."

Milestone 1 — Customized Editor

Goal: a VS Code setup (or your editor of choice) tuned to how you actually work.

Step-by-step

Understand: which languages and frameworks will you use most? What repetitive typing annoys you?
Plan: list the extensions, settings, and snippets that would remove that friction.
Carry out: install and configure the items below.
Look back: open a throwaway project and confirm format-on-save, linting, and snippets all fire.

Essential extensions

ESLint — catch JavaScript/TypeScript problems as you type
Prettier — automatic, consistent formatting
Live Server — instant local preview with reload
GitLens — inline blame and rich Git history
Auto Rename Tag and Path Intellisense — small quality-of-life wins
Plus 1–2 extensions specific to your stack (e.g. ES7+ React snippets, Python, Tailwind IntelliSense)

⚠️ Modern note on brackets

You may see old guides recommend the "Bracket Pair Colorizer" extension. Don't install it — VS Code has bracket-pair colorization built in and it's much faster. Just enable it in settings (shown below).

Settings (VS Code `settings.json`)

{
  "editor.fontSize": 14,
  "editor.fontFamily": "'Fira Code', Consolas, 'Courier New', monospace",
  "editor.fontLigatures": true,
  "editor.tabSize": 2,
  "editor.wordWrap": "on",
  "editor.formatOnSave": true,
  "editor.defaultFormatter": "esbenp.prettier-vscode",
  "editor.bracketPairColorization.enabled": true,
  "editor.guides.bracketPairs": "active",
  "editor.codeActionsOnSave": {
    "source.fixAll.eslint": "explicit"
  },
  "files.autoSave": "afterDelay",
  "files.autoSaveDelay": 1000,
  "workbench.iconTheme": "material-icon-theme"
}

Note the modern "source.fixAll.eslint": "explicit" — newer VS Code replaced the old true/false booleans with the string values "explicit", "always", or "never".

A custom snippet

Create at least three snippets for code you write often. Here's a modern HTML5 starter (in File → Preferences → Configure User Snippets → html.json):

{
  "HTML5 Boilerplate": {
    "prefix": "html5",
    "body": [
      "<!DOCTYPE html>",
      "<html lang=\"en\">",
      "<head>",
      "  <meta charset=\"UTF-8\">",
      "  <meta name=\"viewport\" content=\"width=device-width, initial-scale=1.0\">",
      "  <title>${1:Document}</title>",
      "  <link rel=\"stylesheet\" href=\"${2:styles.css}\">",
      "</head>",
      "<body>",
      "  $0",
      "  <script src=\"${3:script.js}\"></script>",
      "</body>",
      "</html>"
    ],
    "description": "HTML5 boilerplate"
  }
}

💡 Make it portable

Turn on VS Code's built-in Settings Sync (sign in with GitHub) so your extensions, settings, and snippets follow you to any machine automatically. That's your "look back" improvement for this milestone.

Milestone 2 — Browser Development Environment

Goal: a browser configured for debugging and research, not just browsing.

Step-by-step

Understand: what do you debug most — layout, network, React state?
Plan: pick extensions and a bookmark structure that match those needs.
Carry out: install, configure DevTools, and build your bookmark folders.
Look back: test the extensions on a couple of real sites.

Extensions

React Developer Tools — inspect component trees and props/state
JSON Formatter — pretty, collapsible JSON in the browser
Wappalyzer — see what tech a site is built with
axe DevTools or Accessibility Insights — catch a11y issues early

DevTools tweaks worth making

Dock to the right or bottom to match your screen shape
Enable request throttling to test slow-network behavior
Set up Workspaces so edits in DevTools save back to your files
Save 2–3 reusable scripts in the Sources → Snippets panel

Bookmark structure

Create folders and fill each with your go-to links:

📁 Docs        MDN · framework docs · language references
📁 Tools       CodePen · regex101 · Can I Use · JWT.io
📁 Resources   icon sets · color pickers · free fonts
📁 Learning    tutorials, courses, cheat sheets
📁 Inspiration well-built sites you want to learn from

Consider a separate browser profile for development so your work extensions and bookmarks stay out of your personal browsing.

Milestone 3 — Project Templates & Scaffolding

Goal: reusable folder structures plus a script that spins up a new project in seconds.

Template structures

Create at least two of these. Note the clean separation of concerns — controllers, models, routes, and services each get their own home:

frontend-project/          backend-project/
├── public/                ├── src/
│   └── index.html         │   ├── controllers/
├── src/                   │   ├── models/
│   ├── components/        │   ├── routes/
│   ├── pages/             │   ├── middleware/
│   ├── services/          │   ├── services/
│   ├── utils/             │   ├── utils/
│   ├── styles/            │   └── app.js
│   └── main.js            ├── config/
├── tests/                 ├── tests/
├── .gitignore             ├── .env.example
├── package.json           ├── .gitignore
└── README.md              └── package.json

A scaffolding script

Automate project creation with a small shell script. This modern version quotes variables (to survive spaces in names), uses a portable rsync/cp copy, and initializes Git:

#!/usr/bin/env bash
# project_init.sh — usage: ./project_init.sh <name> [frontend|backend|fullstack]
set -euo pipefail

PROJECT_NAME="${1:-}"
TYPE="${2:-fullstack}"
TEMPLATES_DIR="$HOME/dev/templates"

if [[ -z "$PROJECT_NAME" ]]; then
  echo "Error: please provide a project name"
  echo "Usage: ./project_init.sh <name> [frontend|backend|fullstack]"
  exit 1
fi

case "$TYPE" in
  frontend|backend|fullstack) ;;
  *) echo "Error: invalid type '$TYPE' (frontend|backend|fullstack)"; exit 1 ;;
esac

mkdir -p "$PROJECT_NAME"
cp -R "$TEMPLATES_DIR/$TYPE/." "$PROJECT_NAME/"
cd "$PROJECT_NAME"

# Replace the PROJECT_NAME placeholder in text files
grep -rl "PROJECT_NAME" . | xargs sed -i "s/PROJECT_NAME/$PROJECT_NAME/g"

git init -q
git add .
git commit -q -m "chore: initial project scaffold"

[[ -f package.json ]] && npm install

echo "✅ $TYPE project '$PROJECT_NAME' is ready."

⚠️ A portability note

The sed -i flag differs between GNU (Linux) and BSD (macOS) — on macOS you'd write sed -i ''. If you want one script that runs everywhere, a small Node.js or Python scaffolder avoids this platform quirk entirely. Something to note in your "look back."

Config templates to include

Add ready-to-copy versions of the files every project needs: .gitignore, .prettierrc, eslint.config.js (the modern flat-config format), .env.example, and a starter README.md.

Milestone 4 — Task-Management System

Goal: a working board that connects the Agile and productivity ideas from the last two lessons to your real work.

Board columns

Set up a Kanban board (Trello, GitHub Projects, or Notion) with a WIP limit on "In Progress":

Backlog → This Week → Today → In Progress (WIP 2) → Review → Done

Labels

Type: Feature · Bug · Refactor · Docs
Priority: High · Medium · Low
Effort: S · M · L (or story points)
Area: Frontend · Backend · Database

A reusable task template

Give every card a consistent shape so nothing important gets forgotten:

## Objective
What needs to be done, in one sentence.

## Acceptance criteria
- [ ] Condition 1
- [ ] Condition 2

## Notes / resources
Links, dependencies, design references.

## Polya check
- Understand: ...
- Plan: ...
- Look back: ...

💡 Close the loop

The task template's "Polya check" ties this milestone back to your compass. Filling it in for real tasks is how the framework becomes a habit instead of a poster on the wall.

Completion Checklist

You've finished the project when you can tick every box below. Put your workspace config, templates, and scripts in a public GitHub repo with a README that explains your choices.

✅ Definition of Done

☐ Editor has your extensions, a tuned settings.json, and ≥3 custom snippets
☐ Settings Sync (or an exported settings file) makes the setup portable
☐ Browser has dev extensions installed and a working bookmark folder structure
☐ At least two project templates exist and are committed
☐ The project_init.sh script creates a fresh, Git-initialized project end to end
☐ A task board exists with columns, a WIP limit, labels, and the task template
☐ A repo README documents the setup and how Polya's framework is wired in
☐ You've tested the whole thing by scaffolding and committing one small sample project

What Good Looks Like

A checklist tells you if you finished; this section tells you whether you finished well. Compare your result against these signals.

Signal	Just okay 🙂	Genuinely good ⭐
Editor	A pile of extensions installed	Every extension earns its place; format-on-save and lint-fix are automatic and invisible
Scaffolding	Templates exist but you copy them by hand	One command produces a ready-to-code, Git-initialized project
Task board	Columns exist but WIP is ignored	WIP limit is respected; cards use the template; the board reflects reality
Documentation	README says "my setup"	README explains why each choice was made — a future teammate could adopt it
Process	You built it ad hoc	You can point to Polya's steps you took at each milestone

📖 The real deliverable

The workspace is valuable, but the habit is the point: understanding a problem before planning, planning before building, and always looking back to improve. That loop is what separates a coder from an engineer.

Wrap-up & Quiz

🎉 Key Takeaways

A workspace is editor + browser + templates + task system, set up once and reused forever.
Polya's four steps — understand, plan, carry out, look back — guide both this project and every future one.
Automation (snippets, a scaffolding script, board automation) removes friction so you focus on real problems.
Good work is documented and intentional, not just complete — the README should explain your why.

🎯 Quick Quiz

Question 1: In Polya's framework, what is the purpose of the final "Look back" step for a developer?

Question 2: Why should you write a scaffolding script like project_init.sh instead of copying template folders by hand?

Question 3: What separates a "genuinely good" workspace README from a "just okay" one?

📚 Further Reading

🚀 What's Next?

Module 1 is complete — you have the environment, the mindset, and the workflow. Next module we go deeper into the single most important tool in that workspace: version control. We'll start with the concepts and history behind Git before putting it to work.

🎉 Module 1 complete!

Your workshop is built. Time to master the tool every professional developer reaches for first — Git.

What You're Building

✅ Why this matters

Your Compass: Polya's Framework

Milestone 1 — Customized Editor

Step-by-step

Essential extensions

⚠️ Modern note on brackets

Settings (VS Code settings.json)

A custom snippet

💡 Make it portable

Milestone 2 — Browser Development Environment

Step-by-step

Extensions

DevTools tweaks worth making

Bookmark structure

Milestone 3 — Project Templates & Scaffolding

Template structures

A scaffolding script

⚠️ A portability note

Config templates to include

Milestone 4 — Task-Management System

Board columns

Labels

A reusable task template

💡 Close the loop

Completion Checklist

✅ Definition of Done

What Good Looks Like

📖 The real deliverable

Wrap-up & Quiz

🎉 Key Takeaways

🎯 Quick Quiz

📚 Further Reading

🚀 What's Next?

🎉 Module 1 complete!

Settings (VS Code `settings.json`)