Your code ships, but your code reviews sound overly formal—or maybe too casual. Learn the exact English phrasing top developers use to communicate clearly in PRs, RFCs, and async channels without friction.
Try Amélie free →French speakers often struggle with the pragmatics of tech English: directness without rudeness, async clarity without endless explanation, and feedback that lands right. Native speakers write "Use const here"; non-natives often write "I would kindly suggest we might consider using const, if it is not too much trouble." In code reviews, RFCs, and Slack threads, every word counts—and the wrong tone kills momentum. This cluster teaches you how developers actually communicate in async-first teams, with the technical vocabulary and unwritten rules that vary wildly from formal English training.
In async communication, hedging language ('Perhaps we could consider...') reads as indecisive. Write: 'Use const here' or 'This is a performance risk.' Directness + presence = confidence. French politeness rules don't apply in technical chat—developers expect clarity over elaboration.
You can't have a Slack back-and-forth in real time. Assume the reader will only see your message once, so include the 'why,' not just the 'what.' 'This doesn't scale—we'd hit rate limits at ~5k concurrent users' works. 'This doesn't work' doesn't.
Say 'This function mutates state'—not 'This function would mutate state' or 'It could mutate.' Present tense feels factual and less apologetic. It's what you're reading right now, not what might theoretically happen.
French might soften commands ('Would you mind...?'). English code reviews? 'Add error handling here.' 'Rename to getOAuthToken().' It's not an insult; it's a direction. The reader expects it.
Lead with the core ask ('This needs unit tests'), then rationale ('Without them, we can't safely refactor later'). Save nice-to-haves for the end. Async readers skim; frontload importance or they'll miss your point entirely.
"We should extract this logic into a helper" is collaborative without being weak. "I personally think you might want to..." is weak. Avoid 'I think/I believe'—just state the proposal or observation.
A thumbs-up and a 'This is suboptimal 😅' still reads as criticism if the reason isn't clear. Focus on clarity first. An emoji doesn't make vague feedback less frustrating; specificity does.
They're not being harsh—they're being efficient. Async communication removes tone cues, so directness = clarity. 'This won't scale' sounds blunt in person. In a PR thread, it's the most helpful thing you can read because it's immediate and testable. French tends to soften speech for politeness; English code culture prioritizes signal-to-noise.
Lead with specificity, not softening. 'This function is O(n²) and will timeout on large datasets' is criticism, but it's useful. 'I'm not totally sure but maybe this could be slow?' is unclear and gets ignored. Directness + explanation = professional feedback. Hedging + apology = looks like you don't believe your own feedback.
'LGTM' (Looks Good To Me) is standard in tech, especially for smaller PRs. It signals you've approved without ceremony. If you have caveats, write them separately: 'LGTM, pending tests.' For bigger reviews, write 'Looks good' or 'Ship it' with your feedback. The shorthand works because teams agree on the meaning—it's not lazy, it's efficient.
More than you think. In async, the author can't ask follow-up questions in real time. Give context: the potential issue, why it matters, and what would fix it. 'Extract this to a helper' is too short. 'Extract this logic into a separate function to make it testable in isolation—right now it couples the API response to the UI update' is complete. They either understand and act, or they ask intelligently in the next sync.
The only AI English coach that catches L1 transfer errors. 19,99€/mo — first session free.
Get started →