Asking about a function by name

Lesson 3.2 was about scoping by file. This lesson is about scoping one level finer — by the thing inside the file you actually care about.

If you have a name, you don’t need a location. The name is the question.

Most curiosity in code happens at the level of one function, one component, one class — not one file. A teammate says “the bug is in handleContact.” You hit a stack trace pointing at saveMessage. You read a file and see a call to sendNotification you’ve never traced. You don’t need to find the file first. You just ask in the chat.

The move

Type this into Claude:

where is handleContact and what does it do?

Claude will:

1. Search the project for handleContact.
2. Open the file it lives in.
3. Read the function (and usually the lines right around it).
4. Tell you what it does — in plain English.

You learn where it is and what it does in the same answer. Two birds, one question.

Why this is bigger than it looks

Before Claude, finding a function by name was its own little chore. You’d open the project in an editor, hit “Go to symbol,” scroll through results, try a couple of files, eventually find it. Or you’d run a text search across the project, get a wall of matches, and pick the right one by eye.

That’s not hard. It’s just friction. And friction kills curiosity — most people stop asking the question because finding the answer takes too long.

With Claude, the friction is gone. The question and the answer take the same number of seconds. You can afford to be curious about every name you don’t recognize, instead of only the ones that look important.

A few useful shapes

The basic version:

explain handleContact

When two names sound alike and you’re not sure which is which:

what's the difference between saveMessage and loadMessages in this project?

When you want depth, not just identification:

walk me through saveMessage line by line. What does it do, what does it call, and what does it return?

When you want to know if the function is safe to change:

what calls handleContact? Would changing how it handles errors break anything obvious?

That last shape — “what calls this?” — is its own big idea, and it gets its own lesson next.

The thing that trips people up

Two traps.

First, learners assume Claude needs a perfect spelling. It doesn’t. “Find the function that handles the contact form” works. “There’s something called like contactHandler or handleContact, find it” works. Claude is forgiving about naming — give it a description and it’ll figure out the symbol.

Second, learners assume “find this function” means “find a function by that exact name.” It doesn’t have to. “Find the function that sends the email notification” is a perfectly good question. You’re searching by what it does, not by what it’s called. Sometimes you don’t even know the name yet — and that’s fine.

The unit of curiosity is the thing-you-want-to-understand, not the thing-named-exactly-this.

Connecting to your existing vocabulary

In Lesson 3.7 you learned that a codebase is a folder of files. Files contain functions. Functions are what do things — they’re the verbs of a program.

Most of the time, when something interesting is happening in code, a function is responsible for it. The contact form gets handled because some function ran. The message got saved because some function wrote it down. The email notification went out because some function decided to send it.

Knowing how to ask about functions by name is, in a real sense, learning how to ask about what your software actually does.

What Claude is doing under the hood

When you ask “where is saveMessage?”, Claude does the same hunt you’d do by hand — it searches every file in the project for that name. The difference is what happens next.

The old way dropped a pile of raw matches in your lap: saveMessage appears in server/messages.js (line 12), in server/index.js (line 30), and you’d sort out which is the definition and which is a call by eye. Claude does that reading for you. It opens those files, looks at the lines around each hit, and hands you a sentence: “saveMessage is defined in server/messages.js and called once from server/index.js, where the contact endpoint passes it a message to store.” Same search — none of the friction.

What’s next

Once you can ask about one function, the next obvious question is “and what else touches it?” — where it’s called from, where its return value goes, where the data it relies on comes from. That’s tracing, and it’s the highest-leverage read in this whole level.