English for IT: How to Write Bug Reports, Code Reviews and Emails

October 2026  ·  6 min read

Most of your English at work is written: tickets, pull requests, review comments, Slack messages and emails. Writing is also where non-native speakers have the biggest advantage, because you can take your time and use templates. Below are templates you can copy, before-and-after rewrites, and the grammar mistakes that show up most often in developer writing.

1. Bug Reports and Tickets

A bug report has one job: let someone else reproduce the problem without asking you questions. Use the same structure every time.

Template:

• Title: [Where] + [what goes wrong] + [when]
• Steps to reproduce: numbered, one action per line
• Expected result: what should happen
• Actual result: what happens instead, with the exact error text
• Environment: browser, OS, app version, environment (staging/prod)
• Notes: frequency, screenshots, logs, workaround

Before: “Login not working!!! Please fix urgent.”

After:

• Title: Login page returns 500 error when email contains a plus sign
• Steps: 1. Open /login on staging. 2. Enter test+1@example.com and a valid password. 3. Click “Sign in”.
• Expected: The user is signed in and redirected to the dashboard.
• Actual: “Internal Server Error”. The API responds with 500.
• Environment: Staging, build 2.14.0, Chrome 129 on Windows 11.
• Notes: Happens every time. Emails without “+” work. Probably related to URL encoding.

Notice the tone: no capital letters, no exclamation marks. If something is urgent, say why: “This blocks the release on Thursday.”

2. Pull Request Descriptions

The code shows what changed. Your description should explain why and tell the reviewer where to look.

Template:

• What: one or two sentences on the change.
• Why: the problem or ticket it solves.
• How: the approach, and any alternative you rejected.
• Testing: how you checked it.
• Notes for reviewers: risky areas, follow-ups, screenshots.

Before: “fixed bug”

After: “Encode the email parameter before calling the auth API. Fixes LOGIN-482: users with a ‘+’ in their email got a 500 error. I used the standard encoder instead of a custom regex. Added unit tests for ‘+’, ‘%’ and spaces. The change in auth/client.ts is the important one; the rest is renaming.”

3. Code Review Comments

In review, direct translations from Russian, Turkish or Portuguese often sound like orders. English reviewers usually soften comments and make clear how important each one is.

Useful labels many teams use: “Nit:” (tiny, optional), “Optional:”, “Question:” (not a request), “Blocking:” (must fix before merge). They save the author from guessing.

Replying to review comments:

• “Good catch, fixed in the latest commit.”
• “I see your point, but I’d prefer to keep it because… Happy to discuss.”
• “Agreed. I’ve created a follow-up ticket, since it’s out of scope here.”

4. Status Update Emails

Busy managers read the first two lines. Put the status there, then details.

Template:

• Subject: [Project] status, [date]: [on track / at risk / blocked]
• Summary: one sentence.
• Done: bullet list.
• Next: bullet list.
• Risks or blockers: what you need and from whom.

Example: “Subject: Payments migration status, 14 Oct: at risk. Hi all, the migration is about two days behind because the sandbox API was down on Monday. Done: data mapping and tests for card payments. Next: refunds, then load testing. Blocker: we need production API keys from the finance team by Thursday to keep the release date.”

5. Asking for Help

Show what you have already tried. People help faster when the question is easy to answer.

Before: “Hi” (then waiting) … “Docker not working, can you help?”

After: “Hi Tom, quick question about the local setup. docker compose up fails with ‘port 5432 already in use’. I’ve stopped my local Postgres and restarted Docker, but the error is still there. Have you seen this before? No rush, any time today is fine.”

Write the whole question in one message. A lone “Hi” makes the other person wait for the real question.

6. Declining or Pushing Back on Scope

Saying “no” directly can sound rude in English. Saying “yes” to everything is worse. The pattern is: acknowledge, explain the constraint, offer an option.

• “I understand why this matters. With the current deadline, I can’t add it without dropping the export feature. Which one should I prioritise?”
• “That’s a good idea, but it’s out of scope for this sprint. Shall I add it to the backlog?”
• “I’m not able to take this on this week. I could look at it on Monday, or Ali might have capacity.”

Avoid “It is impossible” and “This is not my task”. Both are direct translations that sound much stronger in English than intended.

7. Common Grammar Mistakes in Developer Writing

• Missing articles: “I fixed bug in parser” → “I fixed a bug in the parser”. Speakers of Russian, Kazakh and Turkish often drop a and the; they matter more than you think.
• Uncountable nouns: “informations”, “feedbacks”, “advices” → “information”, “feedback”, “advice”.
• Present perfect for recent results: “I fixed it already” is fine in American English, but “I’ve fixed it” is the safer default for status updates.
• “Since” and “for”: “The build has been failing since Monday” / “for two days”, not “from two days”.
• Questions without inversion: “You can check it?” → “Could you check it?”
• “Please” does not soften an order enough. “Please fix it today” still sounds like a command; “Would you be able to fix it today?” sounds collaborative.
• Commit messages: use the imperative, “Add retry to upload”, not “Added” or “Adding”.

Need the vocabulary behind these templates? See technical English vocabulary for developers. For spoken situations, read English for stand-ups and IT meetings. Derstina’s English for IT courses include lessons on exactly these tasks (tickets, code reviews, documentation and emails) at every level from A1 to C2.

Frequently Asked Questions

How do I write a good bug report in English?

Use a fixed structure: a clear title, numbered steps to reproduce, the expected result, the actual result with exact error text, and the environment. Keep sentences short and neutral, and if the bug is urgent, explain the impact instead of using capital letters or exclamation marks.

How do I write polite code review comments?

Describe the problem, not the person, and phrase changes as questions or suggestions, such as “Could you add a check here?” Label comments as “Nit”, “Optional”, “Question” or “Blocking” so the author knows what must change before merging.

What does “nit” mean in code review?

“Nit”, short for “nitpick”, marks a very small, optional comment, such as a variable name or formatting. The author can fix it or ignore it, and it should not block the merge.

Should commit messages be in the past tense?

Most teams use the imperative mood, for example “Fix null check in parser”, because it describes what the commit does when applied. Follow your team’s convention if it is different.

How do I say “no” to extra work politely in English?

Acknowledge the request, explain the constraint, and offer an option. For example: “I understand why this matters, but with the current deadline I can’t add it without dropping another feature. Which one should I prioritise?”