Asking about a function by name

Lesson 4.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 handleLogin.” You hit a stack trace pointing at User.save. You read a config and see a call to useAuth you’ve never heard of. You don’t need to find the file first. You just ask.

The move

where is handleLogin and what does it do?

Claude will:

1. Search the project for handleLogin.
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 grep for the name, 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 handleLogin

When the same name might exist in more than one place:

there are two functions called save in this project — what's the difference?

When you want depth, not just identification:

walk me through User.save 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 handleLogin? 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 logins” works. “There’s something called like loginHandler or handleLogin, 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 welcome email” 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. Login happens because some function ran. The dashboard rendered because some component (which is just a function) was called. The email 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.

The grep behind the question

Remember that “wall of matches” — the old, slow way to hunt down a function before Claude? Let’s actually run it, because it’s exactly what Claude does the instant you ask “where is handleLogin?”

You’re in the taskly project again. Search every file for the name:

grep -rn "handleLogin" .

grep finds text inside files. The -r means search everything in here, folders and all; -n means show me the line numbers. Read what comes back: handleLogin is defined in src/auth.ts and called over in src/routes.ts.

That’s the search Claude runs for you. The difference is what happens next: instead of dropping a pile of raw matches in your lap to sort through by eye, Claude opens those files, reads around each hit, and tells you in a sentence what the function does and where it lives. Same grep — 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.