ESL at Work: Practice Log 1, Prepping a Weekly Sync

2026/02/23

LIVEai-toolingesl

This is the first entry in a series. The idea: I document actual ESL practice sessions where I use Claude Code to reduce the cognitive load of being an engineer who thinks in Chinese but works in English. Not theory — the real prep artifacts, what worked, what didn’t.

If you want the “why” behind all of this — the two-mode framework, the guilt thing, the long-term vision — I wrote a companion post that covers the philosophy. This series is the workout log. That post is the training manual.

Today’s session: prepping for my DevEx squad weekly sync.

The situation

Every week our squad does a sync. Six or seven people. Everyone shares status. People ask follow-up questions. On paper it’s a 30-minute meeting. In practice it’s 30 minutes of real-time English generation under social observation, which for an ADHD+ASD brain running ESL firmware is… a lot.

What I needed:

What Claude pulled

I asked Claude to help me prep. It reached into three data sources automatically:

Git/GitHub. 15 PRs across our two main repos (yolo and mango). 4 merged this week, several drafts still in flight. This is the ground truth — what I actually shipped vs. what I think I shipped.

Linear. 9 tickets telling the full torch unblocking story (DEVEX-254, 332–339). 3 done, 3 in progress, 3 backlog. This is the narrative — what the work is about, not just the individual commits.

Slack. Nothing this time. I didn’t have Slack threads queued for this meeting. Future improvement: pull relevant threads automatically based on ticket mentions.

The data pull took maybe 20 seconds. Manually assembling this from three browser tabs would have taken 15 minutes and I would have forgotten at least one PR.

The status summary

Claude synthesized everything into a narrative. Abbreviated version:

Main story: Torch unblocking. Split into two paths.

Also in flight: Batch-migrate 22 packages PR, AI fix workflow improvements, uv-stable.lock for Docker cache.

Merged this week: AI failure analysis pipeline, ACR retry config, py_pytest_test macro, ACR regional endpoints.

This is useful on its own — it’s the cheat sheet I’d glance at during the meeting. But it’s not where the language practice happens.

The phrases

Claude generated exact sentences to practice saying out loud. A few:

Status opener:

“Main thing this week was torch unblocking. I split it into two paths — one for packages that don’t actually need torch, and one for the ones that do.”

Explaining Path A:

“Path A is done. About fifty packages were importing mai_config which pulled in torch transitively. I made that optional, so they can migrate to Bazel without dealing with torch at all.”

Blocker response (if asked):

“No hard blockers right now. Path B depends on figuring out the right CI override mechanism, but I have a couple approaches to test.”

Recovery phrase (when you don’t understand a question):

“Can you say more about that? I want to make sure I’m following.”

I practice these out loud. Not reading — saying. Mouth moves, words come out, brain builds the motor pathway. It feels stupid. It works.

But here’s the thing I realized during this session: phrases only cover the monologue part. The status update where everyone politely listens. That’s the easy part.

The conversation script (the new thing)

The hard part is the back-and-forth. Someone asks a follow-up. Your phrase sheet doesn’t cover it. Now you’re composing English in real time while also thinking about the technical answer while also managing the social pressure of six people watching you think.

So I asked Claude to generate screenplay-format mock conversations:

RYAN: So what's the status on the torch migration?

YOU: Path A is done — mai_config no longer requires torch
     at import time. Path B is in progress, I'm working
     on the Linux CI override.

RYAN: Nice. What's the timeline?

YOU: Probably this week, if the override approach is clean.

     (if you're not sure about timeline:)
YOU: Still scoping it — I'll have a better estimate
     after I test the mechanism.

MASATOSHI: Does the batch migration PR depend on
           the torch changes landing first?

YOU: Nope, they're independent. The batch PR is for
     packages that are already torch-free.

     (if you need to hedge:)
YOU: Most of them are independent. Let me double-check
     the dependency list and flag any that overlap.

SOMEONE: [question you don't fully understand]

YOU: Sorry, can you rephrase that? I want to make sure
     I'm answering the right thing.

     (or:)
YOU: Just to clarify — are you asking about [X] or [Y]?

A few things that make this work:

Real names. Not “Teammate A.” When Ryan actually asks a question in the meeting, the script fires from memory instead of from scratch. It’s priming.

Branching responses. The (if X, say Y) format. You can’t predict exact questions, but you can predict categories — timeline, blockers, dependencies, scope — and pre-load a response for each. It turns real-time generation into pattern matching.

Recovery phrases built in. Every script ends with what to say when you’re lost. Having these pre-loaded means you never freeze. You reach for “can you rephrase that?” while your brain catches up.

Short responses. Two, three sentences max. This is how people actually talk in syncs. And fewer words means fewer chances to trip over grammar mid-sentence.

Here’s the insight that landed during this session: native speakers prep talking points too. They just do it in their head, because generating English is free for them. I’m doing the exact same thing — I just need to externalize it because the generation step has a cost. That’s not cheating. That’s compensating for a hardware difference with better software.

Bonus scripts: things I want to bring up

Not everything in a meeting is reactive. Sometimes you have a thought — something you’ve been chewing on — and you want to raise it. This is harder than status updates because there’s no structured prompt. You’re initiating, not responding.

Here are two I prepped for this week. Neither is a status update. Both are opinions I want to express, which means the language has to land right or the idea gets dismissed before it’s heard.

“Why are we always firefighting?”

The Chinese concept is 救火 — literally “saving fire.” Every sprint starts with a plan. By Wednesday someone’s debugging a CI meltdown or chasing a flaky test regression. The plan dies. Repeat.

YOU: I want to flag something — it feels like we spend a lot of time
     firefighting. Like, every week something breaks and we context-switch
     into fixing it, and the planned work just... doesn't happen.

SQUAD LEAD: Yeah, that's fair. What are you thinking?

YOU: I'm not sure I have a solution yet. But I think we should at least
     track it — like, how much of our sprint capacity goes to unplanned
     reactive work versus what we actually planned.

     (if someone pushes back with "that's just how infra is":)
YOU: I get that incidents happen. But there's a difference between
     "incidents happen" and "incidents are our full-time job."
     I think we can reduce the fire surface, not just get faster
     at putting out fires.

     (if someone asks "what would you change?":)
YOU: Honestly? More investment in CI reliability and alerting quality.
     Half the fires start because we found out too late.
     If we catch things earlier, they're smaller fires.

     (recovery if the conversation moves to something you didn't expect:)
YOU: Let me think about that more — I want to come back with
     something concrete next week.

Key phrases to practice out loud:

“Can we use Linear (or something) to see what everyone’s working on?”

This one’s about team visibility（团队可见性）. Right now, figuring out what each person is doing requires asking them in Slack or waiting for the sync. There’s no shared board. No single view.

YOU: One thing I've been thinking about — we don't really have
     visibility into what everyone's working on day to day.
     Like, I know what I'm doing, and I vaguely know what
     Ryan's doing, but that's about it.

RYAN: Yeah, we've talked about that before. What are you proposing?

YOU: Something like Linear or a shared board. Not for micromanaging —
     just so when someone asks "who's working on X" or "is anyone
     blocked" we don't have to play Slack detective.

     (if someone says "we tried that, nobody updates it":)
YOU: Yeah, that's the risk. I think the key is keeping it lightweight.
     Like, three statuses: backlog, in progress, done. No subtasks,
     no story points, no ceremonies. Just enough that you can glance
     at a board and know the state of the world.

     (if someone asks "why not just use GitHub issues?":)
YOU: We could. The issue is GitHub issues live per-repo, and our work
     spans multiple repos. I want one view across everything.
     That's where something like Linear helps.

     (if a lead says "let me think about it":)
YOU: Totally. Happy to set up a prototype if it'd help —
     like, mock up what the board would look like for our squad.

     (if you sense resistance and want to retreat gracefully:)
YOU: No pressure — just floating it. If people think it'd be useful,
     I can put something together. If not, no worries.

Key phrases:

What I like about prepping these: the technical vocabulary is easy. I know what Linear is, I know what CI reliability means. The hard part is the social vocabulary — hedging, retreating, inviting discussion without forcing it. Those are the phrases that freeze up under pressure. Pre-loading them makes the difference between “Zoe had a good point” and “Zoe said something but I’m not sure what she meant.”

What I’d do differently next time

Pull Slack threads. Some of my status updates reference conversations that happened in Slack — decisions that were made, questions that came up. Next time I want those in the prep context so Claude can reference them in the scripts.

Record what actually happened. After the meeting, I should note which phrases I used, which follow-up questions actually came up, and where I froze. That’s the feedback loop. Without it, I’m just running the same warm-up every week without knowing if it’s working.

More branch depth. Some of the scripts only go two exchanges deep. Real conversations go three or four. I want scripts that handle “and then they ask a follow-up to the follow-up.”

What’s next in the series

This was meeting prep. Future entries will cover:

We’ll see which one comes next. Depends on which scenario ambushes me first.