Clayton MethodClayton Method
</> Start Here · A Plain-English Guide

How code actually works

No jargon, no prior experience. Just what's happening under the hood — and how to read it, and change it, without breaking everything.

01

The one idea everything rests on

Code is just a list of instructions, written down for a computer to follow — like a recipe. The computer does exactly what the instructions say, in order, very fast, and not one thing more. It never guesses what you meant. That's the whole secret: when something breaks, it's almost never magic — a step is missing, out of order, or spelled in a way the computer doesn't recognize.

Different "languages" are just different ways of writing those instructions, each suited to a different job — the same way a recipe, a knitting pattern, and sheet music are all instructions, but for different things. You don't need to write them fluently to be useful. Being able to read a few lines and know which one to nudge is most of the battle.

02

The families of code

You'll meet these by name constantly. Here's what each one is for — so when you open a file, you know what you're looking at.

.html

HTML

Structure · the bones

Defines what's on the page and in what order — headings, paragraphs, buttons, images. It's the skeleton. If you want to change the words on a page, this is usually where they live.

.css

CSS

Style · the paint

Controls how it looks — colors, fonts, spacing, sizes, layout. Same bones, totally different outfit. Change a color or a font here and nothing about the content breaks.

.js

JavaScript

Behavior · the verbs

Makes things happen — what occurs when you click, type, scroll, or submit. The interactivity. More powerful, so also the easiest of the three to break. Edit gently.

.py

Python

General purpose

A friendly, readable language used for automation, crunching data, scripts, and most AI work. Reads almost like English, which is why beginners and scientists both love it.

SQL

SQL

Talking to databases

The language for asking a database questions — "give me every customer in Texas who ordered last month." If your data lives in a table somewhere, SQL is how code fetches it.

JSON

JSON

Not a language · a container

A tidy way to store and pass around information, written as labelled pairs. Not instructions — just data. You'll see it everywhere settings or content get saved.

03

The building blocks every language shares

Learn these five ideas once and you can half-read almost any language. The words differ; the concepts don't.

VariablesA labelled box that holds a value so you can use it by name later.
let firstName = "Cassie"; ← the box "firstName" now holds Cassie
FunctionsA reusable recipe you give a name, then "call" whenever you need it.
function greet(name) { return "Hello, " + name; } greet("Cassie") → "Hello, Cassie"
Conditionals"If this is true, do that — otherwise, do something else."
if (cart > 0) { showCheckout(); } else { showEmptyCart(); }
Loops"Do this same thing for each item" — so you don't repeat yourself.
for each product in catalog { printPrice(product); } ← runs once per product
CommentsNotes for humans. The computer ignores them completely — safe to read, safe to add.
// This line does nothing when run. // It's just here to explain the next bit.
04

Reading a real line, piece by piece

Here's a snippet of HTML with a touch of CSS — the kind of thing you'll actually open. Same colors as above, so you can spot each part.

<!-- a heading and a button --> <h1 class="title">The Clayton Method</h1> ← the words people see live between the tags <button>Book a call</button> /* and the style that paints them */ .title { color: #133D2E; ← change this value to recolor the heading font-size: 48px; ← bigger number = bigger text }

The pattern to notice: tags come in pairs that wrap content — <h1>…</h1> — and the closing one just has a slash. The text between them is what shows up on screen. The style block is a list of property: value; pairs. The values (a color, a number) are the safest thing to change. The punctuation around them — the braces, colons, semicolons — is the structure holding it together.

05

How a whole project fits together

A project isn't one giant file — it's a folder of files that reference each other, like a binder with labelled tabs. A typical website folder might hold:

my-website/ index.html ← the home page (the "front door") styles.css ← how everything looks script.js ← what everything does images/ ← a folder of pictures

"Running" the code just means handing those files to something that can follow the instructions — your browser opens the HTML and obeys it, drawing the page. index.html is almost always the starting point, the page that loads first.

You'll also hear front-end vs back-end. Front-end is everything you see and click (the storefront). Back-end is the machinery behind the curtain — databases, logins, payments (the stockroom). Most of what you'll want to tweak — words, colors, layout — lives on the front-end.

06

Changing code without fear

You said you can read code and want to manipulate it. This is the playbook for doing that safely.

1

Keep a copy first

Before you touch anything, duplicate the file. If it all goes sideways, you delete your version and you're back to safe.

2

Change one thing at a time

Edit, look at the result, repeat. If you change five things and something breaks, you won't know which one did it.

3

Text in quotes is friendly

Words inside "…", color values, and plain numbers are the safest to change. They're content, not structure.

4

Leave the punctuation alone

The brackets { }, ( ), colons and semicolons are scaffolding. Deleting one is the #1 way to break a file.

5

Undo is your safety net

⌘ Z walks back your last change, again and again. Nothing you do in an editor is permanent until you save.

6

Ask before you guess

Paste a confusing line to Claude and ask "what does this do, and what's safe to change?" Reading with a guide beats trial and error.

07

A pocket glossary

The words that get thrown around as if everyone already knows them. Now you do.

Repository ("repo")
The folder that holds a whole project, plus its full history of changes. Lives on your computer and usually a copy on GitHub or GitLab.
Commit
A saved snapshot of your project at a moment in time, with a short note on what changed. Like hitting "save version" with a label.
Bug
Code doing something other than what you intended. Not a mystery — just an instruction that's wrong or missing.
Deploy
Publishing your project so it's live on the internet for real people, rather than just running on your own machine.
API
A doorway one program offers so others can ask it for things — "give me today's weather," "charge this card." How apps talk to each other.
Library / Framework
Pre-written code other people made so you don't start from zero. A library is a toolbox you borrow from; a framework is a whole pre-built workshop.
Syntax
The grammar rules of a language — where the brackets and semicolons go. A "syntax error" means a typo in that grammar, not a flaw in your logic.
Variable
A named box holding a value you can reuse and change. The most fundamental building block of all.
Function
A named, reusable set of steps. Define it once, "call" it by name as often as you like.
Frontend / Backend
What you see and click (frontend) versus the hidden machinery — data, logins, payments (backend).