How Reading Pull Request Descriptions Improved My English More Than Any Course

DevGlish Team

Two years ago, I spent ¥30,000 on an English conversation course marketed at professionals. We practiced self-introductions, discussed weekend plans, and role-played ordering food at restaurants. After eight sessions, I could confidently ask for the check at an imaginary café. But I still couldn't write a clear pull request description.

The disconnect was obvious in retrospect. I don't order food in English — I live in Tokyo. I write code reviews in English, I read documentation in English, I communicate with overseas colleagues in English. The English I needed wasn't conversational; it was technical, written, and async.

The resource that actually improved my professional English wasn't a course. It was reading pull requests on GitHub.

Why PRs are surprisingly good learning material

Open-source pull requests have several properties that make them excellent English learning resources, even though nobody designed them for that purpose:

They use real, professional English. Not textbook English, not tourist English, not formal business English. PR descriptions use the exact register you need for daily work as a developer. The vocabulary, sentence structures, and communication patterns are directly transferable to your own PRs, commit messages, and code reviews.

They have clear structure. A good PR description has a summary, a list of changes, and context for reviewers. This structure makes them easier to parse than free-form writing, and it gives you templates to follow.

They're tied to concrete code changes. Unlike a novel or a news article, a PR description refers to specific, verifiable changes. You can read the description, look at the diff, and verify whether you understood correctly. This feedback loop is powerful for building comprehension.

They demonstrate how experts communicate. When you read a PR from a senior contributor to React or TypeScript, you're seeing how an experienced developer explains technical decisions in English. You're learning not just vocabulary but judgment — what to include, what to omit, how much context to provide.

The projects I learned from

I started with projects I already used as a developer, so I understood the technical context:

TypeScript. The TypeScript team writes exceptionally detailed PRs. Each one explains the problem, the solution, alternatives considered, and potential risks. Reading their PRs taught me how to structure technical explanations in English. I learned phrases like "this addresses the case where..." and "the tradeoff is that..." and "this is intentionally left as a follow-up because..."

Next.js. Vercel's PRs tend to be more concise but very clear. They taught me the value of brevity — how to say "Adds streaming support for Server Components" and have that be sufficient. I learned that you don't need to explain everything in the PR description; the code review conversation fills in the gaps.

Rust. Rust PRs often include detailed performance analysis and before/after benchmarks. Reading these taught me how to present data in English: "This reduces allocation count by ~40% in the common case" or "Benchmark shows no regression on the hot path." The precision of Rust's community influenced my own writing.

I didn't read these PRs cover to cover like a book. I'd spend 10-15 minutes in the morning, during my commute on the train, reading one or two PRs from projects I followed. Over months, this accumulated into a substantial vocabulary and intuition for technical English.

What I actively studied

Reading passively wasn't enough. I developed a practice of actively studying the language patterns I noticed:

I kept a phrase notebook. Whenever I encountered a phrase that felt useful and natural, I'd write it down. Not single words — phrases. "This is a follow-up to #1234" is more useful than knowing the word "follow-up" in isolation. "This was causing flaky test failures" teaches you both "flaky" (intermittent, unreliable) and the pattern "was causing X."

I compared my writing to theirs. After reading a few well-written PRs, I'd go back to my own recent PR descriptions and compare them. The differences were stark. My descriptions were either too brief ("Update user model") or too wordy, explaining things the diff already showed. The good PRs struck a balance I hadn't achieved.

I looked up words I recognized but couldn't define. Words like "regression," "invariant," "idempotent," and "sentinel" appeared frequently in PRs. I knew them vaguely from context, but I couldn't have defined them precisely. Using DevGlish to look these up in their programming context (not their general English meaning) solidified my understanding. "Regression" in software means "a bug introduced by a recent change," which is more specific than the general meaning of "moving backward."

The phrases that transformed my writing

Some phrases I picked up from PRs that I now use constantly:

Each of these phrases is a small tool. Individually, they're just combinations of common English words. Collectively, they give you the vocabulary to participate fully in English-language code review — not as someone translating from Japanese, but as someone speaking the native register of software development.

How this compares to formal study

I don't want to dismiss English courses entirely. Grammar fundamentals, pronunciation practice, and conversation skills all have their place. But for the specific goal of improving your professional English as a developer, reading PRs is more efficient than any course I've tried.

Here's why: courses teach you general English and hope you can apply it to specific contexts. PR reading does the opposite — it teaches you the specific context first, and the general language skills come as a byproduct. After a year of reading PRs, my English emails improved too, not because I studied email writing but because I'd internalized professional English patterns from a related context.

The approach is also free, self-paced, and practically unlimited. There are millions of open-source PRs on GitHub. You'll never run out of material. And unlike a course that meets once a week, you can read PRs during any spare moment — on the train, during a build, while waiting for CI to finish.

Getting started

If you want to try this approach:

Pick 2-3 open-source projects you're familiar with technically. Follow them on GitHub so new PRs appear in your feed. Start reading one PR description per day. Don't worry about understanding everything — focus on the structure and the phrases that recur.

Keep a notebook (digital or paper) of phrases that feel useful. Review it weekly. Try using one new phrase in your own PR description each week.

After a month, go back and read your own recent PRs. Compare them to what you've been reading. The gap will be visible — and narrowing it will feel achievable because you'll have specific models to follow.

The best language learning materials are the ones that teach you the exact variety of language you actually need. For developers, that's not textbook English. It's the English of pull requests, code reviews, and commit messages. And it's sitting on GitHub right now, waiting to be read.

Related Articles