Sign up for freeSign up

Could we maybe…? Polite suggestions with could, might and should

A B1 lesson plan on modals for polite suggestions: English for IT learners turn blunt code review comments into kind ones with could, might and should.

Grammar
Should, could and might want to for suggestions of different strength, and soft frames such as It might be worth adding… and Would it make sense to…?
Topic
Review comments on a mobile team at Kestrel Cloud, a fictional payments startup, with words such as blunt, soften, reasoning and hard-coded value.
Activities
Google's code review guide, a thread of rewritten comments, a review call, self-checking drills, a chat and open boxes, then five kind comments to write and feedback to record.

What's inside

  1. Chapter 1Warm-up: Feedback at Work

    • PictureUnlock
    • Spin the wheel and answer the questionSpin the wheelUnlock
    • Study the words for kind review commentsVocabularyTry it
    • Look at the pictures and choose the wordChoose by pictureUnlock

  2. Chapter 2The Story: Be Kind, Explain Why

    • Read the story: two short rules for reviewersArticleUnlock
    • Choose the correct answer about the storyQuizUnlock

  3. Chapter 3At Work: Five Blunt Comments

    • Read Kenji's post and the team's repliesReal-life documentTry it
    • True or false? Check Kenji's postTrue or falseUnlock
    • Pick the kinder, more useful commentQuizUnlock

  4. Chapter 4Listen: The Refund Screen

    • Listen to Amara and Kenji's review callListeningTry it
    • Transcript, for the teacherUnlock
    • True or false? Check the review callTrue or falseUnlock

  5. Chapter 5Grammar: Could We Maybe…?

    • Study the scheme: suggestions in a reviewGrammar schemeTry it
    • Choose the correct form to complete each commentChoose the optionUnlock
    • Choose should or could: is it important or just an idea?Choose the optionUnlock
    • Fill in the gaps: turn each command into a suggestionFill in the gapsTry it
    • Drag the words into the gaps in Kenji's review commentDrag and dropUnlock

  6. Chapter 6Speak Up: Soften It

    • Choose the best reply to KenjiChatTry it
    • Open a box and make a kind suggestionOpen the boxUnlock

  7. Chapter 7Homework: Your Kind Review

    • Read your phrase bankReal-life documentUnlock
    • Choose the correct suggestionQuizUnlock
    • Unscramble the words from the lessonAnagramUnlock
    • Write five kind review commentsWriting, checked by the teacherUnlock
    • Record spoken feedback on a colleague's workSpeaking, checked by the teacherUnlock

24 exercises in 7 chapters. Start a 7-day free trial to open all of them, copy any part into your own lessons, and teach the lesson live.

Vocabulary

12 words and phrases from the lesson, each with a picture and audio in edio.

+9 more with pictures and audio in the lessonMore words

  • reasoning
  • extract
  • simplify
  • split
  • hard-coded value
  • test case
  • function
  • polite
  • constructive

Grammar: modals for suggestions in code review

A blunt comment gives an order; a useful one makes a suggestion, shows how strong it is and gives a reason. Learners turn commands into suggestions with could, might and should, then add soft frames such as I wonder if we could… and check the form that follows each one.

Suggestions in a review: could, might, should

Make a suggestion, say how strong it is, and give a reason. Watch the word after each frame.

How strong is it?

Should recommends: We should hide the card number before we merge. Could offers an idea the author decides on (You could extract this into a function.), and might want to is softer still. After the modal comes the base verb, so never could to extract.

ModalWhat it meansExample
should + verbI recommend it. It's important.We should hide the card number before we merge.
Should we + verb?I think it's a good idea. Do you agree?Should we rename this function?
could + verban idea: the author decidesYou could extract this into a function.
might want to + verba softer ideaWe might want to add a comment here.

Soft frames: watch the next word

Maybe we could and I wonder if we could take the base verb. Three frames take -ing instead: What about, What do you think about and It might be worth. Would it make sense takes to: Would it make sense to test both names?

FrameNext wordExample
Maybe we could… / Could we maybe…?base verbCould we maybe make the button bigger?
I wonder if we could…base verbI wonder if we could move the amount up.
What about…? / What do you think about…?verb + -ingWhat do you think about moving it to the theme?
It might be worth…verb + -ingIt might be worth adding a test case.
Would it make sense…?to + verbWould it make sense to test both names?

Suggestions from the team

The examples come from the team's rewrites and the review call, from Should we rename getData()? to Could we maybe make the Refund button a bit bigger? Each one replaces a blunt order, such as Wrong name. Rename., with a question or an idea.

  • Should we rename getData()?Wes, in the team chat
  • You could extract the part that formats the amounts.Iryna
  • What do you think about moving this hard-coded green to the theme?Amara
  • It might be worth adding a test case for an empty list.Jordan
  • Could we maybe make the Refund button a bit bigger?Amara, on the call
  • Would it make sense to test both names with a few beta merchants?Amara, on the call

A frame, a suggestion and a reason

A kind comment has three parts: It might be worth adding a test case for an empty list, because new merchants have no payouts yet. Softening is no excuse to skip the reason, and a blocking problem keeps should: blocking: we should fix this before we merge.

A kind, useful comment

soft framethe suggestiona reason

You could extract the QR part, so it's easier to test.

It might be worth adding a test case for an empty list, because new merchants have no payouts yet.

How strong?

should = I recommend it. Use it for important or blocking problems: "blocking: we should fix this before we merge." could / might = just an idea, and the author can say no: "nit: you could use a shorter name." A soft frame never replaces the reason: add because… or so it's easier to…

Typical mistakes

  • You could to extract this.

    You could extract this.

    could / might / should + base verb, no to

  • What do you think about rename it?

    What do you think about renaming it?

    about + verb-ing

  • Should we to add a test?

    Should we add a test?

    Should we + base verb

  • It might be worth to add a comment.

    It might be worth adding a comment.

    worth + verb-ing

More lessons on this grammar: Modal verbs lessons and exercises

Try the modals for suggestions exercises

Try them yourself: these are the same exercises your students do in edio.

More exercises

What's in the lesson

  • 11 auto-checked exercises
  • 3 games
  • 2 teacher-checked tasks
  • 2 real-life documents
  • 1 article
  • 1 grammar scheme
  • 1 set of word cards
  • 1 audio clip
  • 1 picture
  • 1 transcript

The main objectives of this lesson are to:

  • make suggestions with a modal and the base verb: You could extract this. Should we rename getData()?
  • show how strong a point is: should for a blocking problem, could and might for an idea the author can skip
  • use the right form after each soft frame: It might be worth adding…, What do you think about moving…?, Would it make sense to test…?
  • rewrite a blunt review comment as a kind suggestion with a reason: You could extract the QR part, so it's easier to test.

Lesson 11 sits in the middle of Code review, unit 4 of English for IT B1 · Inside the Team, a unit about review comments that are kind and useful. It follows lesson 10's comment labels, builds on should for advice from A2.1 lesson 26 and might for possibility from A2.1 lesson 31, and leads into lesson 12, where the first conditional helps settle a review disagreement. In a review, the modal tells the author whether a point is a request or just an idea.

A wheel of questions about feedback at work opens the lesson, then twelve words for kind comments, from blunt to test case, with pictures and audio. The story covers Google's public code review guide and its two rules for reviewers: be kind, and explain your reasoning. At work, students read Kenji's post with five blunt comments and the team's kinder rewrites, then choose the kinder comment in six situations; in the AI-voiced call, a designer and a tech lead disagree politely about a button name.

The grammar chapter's four self-checking drills include a choice between should and could for eight comments. In the speaking chapter, Kenji helps students soften their own comments in a chat, and open boxes bring prompts, a role-play and questions to discuss. Homework adds a phrase bank, then a quiz and an anagram that check themselves; then students rewrite five blunt comments and record spoken feedback on a colleague's work for the teacher to review.

Grammar:
modals for suggestions · could, might, should · worth / What about + -ing
Topic:
code review · review comments · feedback

Teaching tips

  • Collect blunt comments the group has received, with names removed, and have pairs rewrite each with a frame and a reason; the class then decides whether it reads as a request or an idea.
  • Read the five blunt comments aloud in a flat voice before students see the rewrites; learners say how each one feels, then compare their own versions with the team's replies.
  • Drill the word after each frame in a quick-fire round: call out a verb and a frame, such as rename and What about, and learners answer What about renaming it?
  • For designers and writers in the group, use the homework's comments on screens and documents, such as Too much text or Button too small, so the frames fit their own reviews.

Liked it?

Teach the whole lesson in edio

24 exercises in 7 chapters, ready to teach. edio is an online platform for language schools and teachers: ready-made interactive lessons, live classes, homework and student progress in one place.

  1. Start a free trial

    7 days, no credit card.

  2. Open the lesson

    Find it in the library of 621 ready lessons. Teach it as it is, or copy any chapter into your own lessons.

  3. Teach it live or as homework

    Students work in their own accounts, in sync with you during the lesson, and the practice exercises check themselves.

Teach it free for 7 days

The whole course: English for IT B1 · Inside the Team

24 lessons at B1 for people who build, test or run software, in American English. Learners follow Iryna, a junior developer, through her first year at Kestrel Cloud, a fictional payments startup: standups, tickets, code review, chats across time zones and job interviews. Each lesson is built around a true story from software history.See the course

  1. Unit 1 Hello, team

    roles, stacks and first days: the present simple, the present perfect with for and since, question forms

    1. Lesson 1How big is a two-pizza team?Present simple for jobs and responsibilities
    2. Lesson 2Your first "Hello, World"Present perfect with for and since
    3. Lesson 3Write your personal READMEQuestion forms for getting to know colleagues

  2. Unit 2 The daily standup

    updates and blockers: the present simple and continuous, just, already and yet, have to and need to

    1. Lesson 4Why is it called a scrum?Present simple vs continuous and state verbs
    2. Lesson 5Done, not done yetPast simple, present perfect and going to for updates
    3. Lesson 6Help, I'm blocked!Have to, need to, don't have to and can't

  3. Unit 3 Bugs and tickets

    clear bug reports: the past continuous, imperatives and the zero conditional, quantifiers

    1. Lesson 7The first actual bugPast simple and past continuous for bug stories
    2. Lesson 8Steps to reproduceImperatives and the zero conditional for bug reports
    3. Lesson 9The email that couldn't go 500 milesQuantifiers in bug tickets

  4. Unit 4 Code review

    kind, useful comments: -ed and -ing adjectives, modals for suggestions, the first conditional

    1. Lesson 10What's a nit?-ed and -ing adjectives in review comments
    2. Lesson 11 · you're hereCould we maybe…?Modals for suggestions in code review
    3. Lesson 12Your first pull requestThe first conditional and unless in code review

  5. Unit 5 How it works

    explaining systems step by step: time clauses, the passive, relative clauses

    1. Lesson 13What happens when you type a URL?Time clauses with as soon as, until and once
    2. Lesson 14How is a barcode read?The present and past simple passive
    3. Lesson 15Draw it, then say itDefining relative clauses

  6. Unit 6 Remote and async

    chat, email and time zones: polite requests, future forms, the present perfect continuous

    1. Lesson 16Just say what you needPolite requests and indirect questions
    2. Lesson 17Your 9 a.m. is my noonFuture forms for plans across time zones
    3. Lesson 18Write it downPresent perfect continuous for status updates

  7. Unit 7 Users and clients

    user stories and plain explanations: verb + to or -ing, reported speech, comparisons

    1. Lesson 19As a user, I want…Verb + to or verb + -ing
    2. Lesson 20"The client said it was broken"Reported speech for client calls
    3. Lesson 21Explain it in ten hundred wordsComparisons for plain explanations

  8. Unit 8 Your next job

    resumes and interviews: used to, the past perfect, the second conditional

    1. Lesson 22A resume that shows resultsUsed to for your career path
    2. Lesson 23Tell me about a time when…The past perfect for STAR stories
    3. Lesson 24What would you do if…?The second conditional for interviews

Questions about this lesson

How do you make polite suggestions in English?
Make polite suggestions with a modal or a soft frame, plus a reason: You could extract this into a function, so it's easier to test. Could we maybe make the button bigger? It might be worth adding a test case. A question such as Should we rename this? lets the other person decide. Could we maybe…?, a B1 English for IT lesson on edio.ai, turns blunt review comments into suggestions like these.
Which modal verbs do you use for suggestions?
The main modals for suggestions are should, could and might, each followed by the base verb. Should recommends (We should hide the card number before we merge.), could offers an idea (You could extract this.), and might want to is softer still (We might want to add a comment here.). Should we…? asks for agreement: Should we rename this function?
What's the difference between should and could in a suggestion?
Should marks a point as important; could marks an idea. Use should when something must change: blocking: we should fix this before we merge. Use could or might when the author may say no: nit: you could use a shorter name. A very soft frame can hide a serious problem, so keep should for anything that blocks the change. The chat in the B1 lesson Could we maybe…? on edio.ai tests this split.
What's the difference between what about and how about?
For suggestions, what about and how about mean the same, and both take -ing or a noun: What about doing it next sprint? How about testing both names? The base verb is wrong after them, so not What about move it? What about can also bring up something missing: What about the support team? For a softer suggestion, use What do you think about moving it to the theme?
Is it "it's worth adding" or "it's worth to add"?
It's it's worth adding, because worth takes -ing: It might be worth adding a test case for an empty list. It might be worth asking the support team too. It might be worth to add a comment is a common mistake. A gap-fill in the B1 English for IT lesson Could we maybe…? on edio.ai turns the command Add a test into this frame.
Do you use "to" after could, might and should?
No: could, might and should take the base verb without to. It's You could extract this, not You could to extract this, and Should we add a test?, not Should we to add a test? In We might want to add a comment, the to belongs to want. Would it make sense…? takes to as well: Would it make sense to test both names?
How do you disagree politely at work?
Show you heard the idea, then give your reason: I see your point, but the help articles all say “Issue refund.” That's fair. But in one of my tests, a shop owner asked me what “issue” means. Then suggest a way to decide together: Would it make sense to test both names with a few beta merchants? Amara and Kenji's review call in Could we maybe…?, a B1 lesson on edio.ai, follows these steps.
How do you give constructive feedback in a code review?
Constructive review feedback talks about the code, not the person, and says why, as Google's public code review guide advises. Instead of Why did you do it like this??, write I wonder if we could use our shared date helper here. It already handles time zones. Instead of Function too long. Split., try You could extract the part that formats the amounts into its own function.
How do I teach polite suggestions to B1 adults?
Start from blunt comments and let learners soften them: Too long. Split. becomes You could split it into two smaller functions, so it's easier to read. Group the frames by the form that follows (the base verb, -ing or to), then have learners sort suggestions by strength, should or could. Finish with comments from their own work: code, designs, test plans or documents.
What's good homework for practicing modals for suggestions?
Good homework gives learners blunt comments to rewrite, with a different frame and a reason for each. In the B1 English for IT lesson Could we maybe…? on edio.ai, a quiz and an anagram check themselves first; then learners rewrite five comments on code, a design or a document and record spoken feedback on a colleague's work, two tasks the teacher reviews.
Are there interactive exercises for modals for suggestions?
Yes: gap-fills and chats that check the form after each frame show at once whether worth or about needs -ing. Kenji's post with the team's kinder rewrites, Amara and Kenji's review call, a gap-fill that turns commands into suggestions and a chat with Kenji: these four parts of Could we maybe…?, a B1 English for IT lesson on edio.ai, play on this page without an account. The other exercises are locked.
Unlock full lesson

Teach this lesson with your students

Book a demoStart free trial

No credit card required