Reading code: syntax, errors, logs

You don't need to write code fluently to get massive value out of Claude Code. You do need to readit. Not deeply — just enough to follow what Claude is showing you, spot the weird-looking thing, and ask a sharp question when something doesn't look right. This lesson teaches that minimum.

Code is mostly shapes

Every programming language is just a slightly different way of writing down the same handful of ideas: store a value, do something if a condition holds, do something for each item in a list, group instructions into a named unit. Once you recognise those shapes, you can skim almost any file in any language and grasp the gist.

Here are the shapes, with examples in JavaScript:

// 1. A variable: a labelled box holding a value
const name = "Harvey";
const age = 30;

// 2. A condition: do different things based on a check
if (age >= 18) {
  console.log("adult");
} else {
  console.log("minor");
}

// 3. A loop: do the same thing for each item
const friends = ["Sam", "Lee", "Jo"];
for (const friend of friends) {
  console.log("Hi " + friend);
}

// 4. A function: a reusable block with a name and inputs
function greet(person) {
  return "Hello, " + person;
}
greet("Harvey");  // returns "Hello, Harvey"

That's 90% of what you'll see in any code file: variables, conditions, loops, functions. Different languages spell it differently — Python uses indentation where JavaScript uses curly braces, for instance — but the shapes are the same.

Reading a file you've never seen

The strategy that actually works:

1. Look at the file name first. A file named userProfile.tsx is doing something with user profile UI. auth-helpers.ts is utility code for authentication. The name is half the documentation.
2. Read the imports at the top. They tell you what other code this file depends on. If you see import { useState } from "react", this is a React file.
3. Scroll to the main thing exported. Look for export defaultor the biggest function. That's usually what this file is "about."
4. Read the function names and comments. Skip the implementation details. function validateEmail(input) tells you everything you need to know without reading the body.

Reading errors and stack traces

When code goes wrong, you get an error message — often a wall of text called a stack trace. New developers panic at these. Don't. They're structured and full of useful information.

Traceback (most recent call last):
  File "app.py", line 24, in <module>
    result = calculate_total(items)
  File "app.py", line 15, in calculate_total
    return sum(item.price for item in items)
  File "app.py", line 15, in <genexpr>
    return sum(item.price for item in items)
AttributeError: 'NoneType' object has no attribute 'price'

How to read it, top to bottom:

• The first line tells you something went wrong.
• The middle is a trail of where the error travelled: the program started at app.py:24, called calculate_total on line 15, which had the actual failure.
• The last line is what actually broke: AttributeErrormeans "tried to look up a property on something that didn't have it," and NoneTypeis Python's word for "nothing, null, missing." So: somewhere an item was unexpectedly missing, and the code tried to read .price off of it.

That's a complete diagnosis without writing any code. You don't need to know Python — you just need to read the message.

Reading logs

Logs are messages a program prints while it runs — either to the terminal or to a file. They tell you what the program is doing, in order. A typical log line might look like:

[2026-05-23 14:22:11] INFO  server started on port 3000
[2026-05-23 14:22:14] DEBUG handling request: GET /api/users
[2026-05-23 14:22:14] WARN  user 42 has no profile photo
[2026-05-23 14:22:14] ERROR database connection lost
[2026-05-23 14:22:15] INFO  attempting reconnect

Notice the structure: timestamp, level (INFO/DEBUG/WARN/ERROR), then the message. When something is broken, you scan the log for the ERRORlines first — they're where the trouble started.

Telling Claude what you see

The whole reason this lesson exists is that you'll be looking at Claude's output a lot, and being able to say "this looks wrong because line 14 calls a function that doesn't seem to exist" is a thousand times more useful than "it looks weird." Sharp questions get sharp answers.

Even if you can't fix the code yourself, pointing at the specific line that smells off lets Claude focus on the right problem instantly.