Mamun Labs Learn
JourneyGlossary
esc
  • Try “map”, “flexbox” or “state”.
Log in
Start learning
Phase 9 · 2 / 3Build with reviews
Phase 9Capstone
3 topics · 4+ wks
  1. 1Plan your app
  2. 2Build with reviews
  3. 3Launch and share
JourneyPhase 9Build with reviews
01 / 08Overview

Build with reviews

You'll learn to build your app in small pieces, ask for a review with a clear pull request, use AI without losing the understanding, and act on feedback.

Why it mattersReviews are how developers learn fastest. In a job, almost every change you make is reviewed before it goes in.
about 10 h·needs: Plan your app, Git and GitHub basics, Using AI as a study partner
02 / 08

Watch & read

Start with the required ones. The others are there when you need them.

Docs
Creating a pull requestGitHub Docs · 10 min · English
MMamun's noteFollow the web browser steps the first time you open a PR. Skip the GitHub CLI and Desktop tabs. You don't need them.
Docs
Helping others review your changesGitHub Docs · 10 min · English
MMamun's noteShort and practical. Read the parts on keeping PRs small, giving context, and reviewing your own PR first. Skip the parts on security tools and Copilot.
ArticleOptional
Commit messagesThe Odin Project · 15 min · English
MMamun's noteHow to write commits that a reviewer can follow. Read it once, then look at your last ten commits and see which ones you would rewrite.
03 / 08

Explanation

You have a plan. Now you build it, over a few weeks. You will not build it alone. After each piece, Mamun (or a mentor) reads your code and leaves comments. This is called a code review.

Think of a cricket net session. A coach does not watch you play a full match and then say "bad". He watches ten balls, fixes your grip, and you play ten more. Small pieces, quick feedback.

Work in small pieces. One screen, or one feature, at a time. For each piece, make a branch: a separate line of work, so main stays working.

git switch -c add-expense-screen
# build, test on your phone, commit as you go
git push -u origin add-expense-screen

On GitHub, open a pull request (PR) from that branch. A PR says "here is my change, please check it before it goes into main". The page shows the diff: every line you added (green) or removed (red).

Write a clear request. Say what the change does, how you tested it, and what you want checked. Add a screenshot. Then say where you are unsure. "I am not sure my total is right when a member is deleted" is the most useful sentence in any PR.

Use AI, and keep the laptop. AI can explain an error, suggest a fix or review your code before Mamun does. The rule from Phase 0 still holds: if you can't explain a line, it doesn't go in the PR. In a review, Mamun may point at any line and ask "why?". "AI wrote it" is not an answer. "It finds the member by id, because names can repeat" is.

Read feedback calmly. A comment is about the code, not about you. Reply to each one. Fix it, or say why you think it should stay. Push the fix to the same branch, and the PR updates itself. When it is approved, merge it, and start the next branch.

People often work for three weeks on one huge branch, then ask for a review of 2000 lines. Nobody can review that well, and the first comment might mean changing everything. Ask for a review every few days, when one screen works.

When you read your own PR before asking, go through the diff line by line. Look for leftover console.log lines, commented-out code, files you did not mean to change, and any line you cannot explain.

Words to recognise
branchpull requestcode reviewdiffreview commentmergefeedback
04 / 08

Code tour

Click a line number with a ring to read the note for that line.

pull-request.md7 notes
Add the expense list screen
Mentor note · line 1
A title that says what the change does, like a good commit message.
2
3What it does
Shows all expenses, newest first, with a total for each member at the top.
5
6How I tested it
Added 6 expenses for 3 members on my phone. Totals match my notebook.
8Closed and opened the app. The expenses are still there.
9
10Screenshot
(expense-list.png)
12
13Please check
- Is computing totals with reduce inside the screen OK, or should it be its own function?
- I am not sure what happens to totals when a member is deleted.
16
17AI use
Asked AI to explain why my FlatList showed a key warning. Wrote the fix myself.
05 / 08

Quick check

3 questions. Each one explains itself after you answer.

  1. 1 / 3You finished the expense list and the add-expense screen. When do you ask for a review?
  2. 2 / 3Mamun points at a line and asks why it is there. AI wrote it and you are not sure. What do you do?
  3. 3 / 3A review comment says "This total is wrong when a member is deleted." What is the best reply?
06 / 08

Explain it back

Only you can see this. Log in to keep it.0 words
07 / 08

How confident are you with Build with reviews?

08 / 08

Done

You can now
Open a small pull request with a clear description, explain every line in it, and turn review comments into fixes.
Next: Launch and share Back to Phase 9
On this page
  1. 01Build with reviews
  2. 02Watch & read
  3. 03Explanation
  4. 04Code tour
  5. 05Quick check
  6. 06Explain it back
  7. 07Confidence
  8. 08Done
Up next · 02 / 08Watch & read
Mamun Labs LearnFound a mistake on this page? Tell Mamun.
Mamun Labs Learn
JourneyGlossary
esc
  • Try “map”, “flexbox” or “state”.
Log in
Start learning
Log in to save your progress. Everything here works without an account.Log in to save progressLog in
Phase 9Capstone
3 topics · 4+ wks
  1. 1Plan your app
  2. 2Build with reviews
  3. 3Launch and share
JourneyPhase 9Build with reviews
01 / 08Overview

Build with reviews

You'll learn to build your app in small pieces, ask for a review with a clear pull request, use AI without losing the understanding, and act on feedback.

Why it mattersReviews are how developers learn fastest. In a job, almost every change you make is reviewed before it goes in.
about 10 h·needs: Plan your app, Git and GitHub basics, Using AI as a study partner
02 / 08

Watch & read

Start with the required ones. The others are there when you need them.

Docs
Creating a pull requestGitHub Docs · 10 min · English
MMamun's noteFollow the web browser steps the first time you open a PR. Skip the GitHub CLI and Desktop tabs. You don't need them.
Docs
Helping others review your changesGitHub Docs · 10 min · English
MMamun's noteShort and practical. Read the parts on keeping PRs small, giving context, and reviewing your own PR first. Skip the parts on security tools and Copilot.
ArticleOptional
Commit messagesThe Odin Project · 15 min · English
MMamun's noteHow to write commits that a reviewer can follow. Read it once, then look at your last ten commits and see which ones you would rewrite.
03 / 08

Explanation

You have a plan. Now you build it, over a few weeks. You will not build it alone. After each piece, Mamun (or a mentor) reads your code and leaves comments. This is called a code review.

Think of a cricket net session. A coach does not watch you play a full match and then say "bad". He watches ten balls, fixes your grip, and you play ten more. Small pieces, quick feedback.

Work in small pieces. One screen, or one feature, at a time. For each piece, make a branch: a separate line of work, so main stays working.

git switch -c add-expense-screen
# build, test on your phone, commit as you go
git push -u origin add-expense-screen

On GitHub, open a pull request (PR) from that branch. A PR says "here is my change, please check it before it goes into main". The page shows the diff: every line you added (green) or removed (red).

Write a clear request. Say what the change does, how you tested it, and what you want checked. Add a screenshot. Then say where you are unsure. "I am not sure my total is right when a member is deleted" is the most useful sentence in any PR.

Use AI, and keep the laptop. AI can explain an error, suggest a fix or review your code before Mamun does. The rule from Phase 0 still holds: if you can't explain a line, it doesn't go in the PR. In a review, Mamun may point at any line and ask "why?". "AI wrote it" is not an answer. "It finds the member by id, because names can repeat" is.

Read feedback calmly. A comment is about the code, not about you. Reply to each one. Fix it, or say why you think it should stay. Push the fix to the same branch, and the PR updates itself. When it is approved, merge it, and start the next branch.

People often work for three weeks on one huge branch, then ask for a review of 2000 lines. Nobody can review that well, and the first comment might mean changing everything. Ask for a review every few days, when one screen works.

When you read your own PR before asking, go through the diff line by line. Look for leftover console.log lines, commented-out code, files you did not mean to change, and any line you cannot explain.

Words to recognise
branchpull requestcode reviewdiffreview commentmergefeedback
04 / 08

Code tour

Click a line number with a ring to read the note for that line.

pull-request.md7 notes
Add the expense list screen
Mentor note · line 1
A title that says what the change does, like a good commit message.
2
3What it does
Shows all expenses, newest first, with a total for each member at the top.
5
6How I tested it
Added 6 expenses for 3 members on my phone. Totals match my notebook.
8Closed and opened the app. The expenses are still there.
9
10Screenshot
(expense-list.png)
12
13Please check
- Is computing totals with reduce inside the screen OK, or should it be its own function?
- I am not sure what happens to totals when a member is deleted.
16
17AI use
Asked AI to explain why my FlatList showed a key warning. Wrote the fix myself.
05 / 08

Quick check

3 questions. Each one explains itself after you answer.

  1. 1 / 3You finished the expense list and the add-expense screen. When do you ask for a review?
  2. 2 / 3Mamun points at a line and asks why it is there. AI wrote it and you are not sure. What do you do?
  3. 3 / 3A review comment says "This total is wrong when a member is deleted." What is the best reply?
06 / 08

Explain it back

Only you can see this. Log in to keep it.0 words
07 / 08

How confident are you with Build with reviews?

08 / 08

Done

You can now
Open a small pull request with a clear description, explain every line in it, and turn review comments into fixes.
Next: Launch and share Back to Phase 9
On this page
  1. 01Build with reviews
  2. 02Watch & read
  3. 03Explanation
  4. 04Code tour
  5. 05Quick check
  6. 06Explain it back
  7. 07Confidence
  8. 08Done
Up next · 02 / 08Watch & read

You have a plan. Now you build it, over a few weeks. You will not build it alone. After each piece, Mamun (or a mentor) reads your code and leaves comments. This is called a code review.

Think of a cricket net session. A coach does not watch you play a full match and then say "bad". He watches ten balls, fixes your grip, and you play ten more. Small pieces, quick feedback.

Work in small pieces. One screen, or one feature, at a time. For each piece, make a branch: a separate line of work, so main stays working.

git switch -c add-expense-screen
# build, test on your phone, commit as you go
git push -u origin add-expense-screen

On GitHub, open a pull request (PR) from that branch. A PR says "here is my change, please check it before it goes into main". The page shows the diff: every line you added (green) or removed (red).

Write a clear request. Say what the change does, how you tested it, and what you want checked. Add a screenshot. Then say where you are unsure. "I am not sure my total is right when a member is deleted" is the most useful sentence in any PR.

Use AI, and keep the laptop. AI can explain an error, suggest a fix or review your code before Mamun does. The rule from Phase 0 still holds: if you can't explain a line, it doesn't go in the PR. In a review, Mamun may point at any line and ask "why?". "AI wrote it" is not an answer. "It finds the member by id, because names can repeat" is.

Read feedback calmly. A comment is about the code, not about you. Reply to each one. Fix it, or say why you think it should stay. Push the fix to the same branch, and the PR updates itself. When it is approved, merge it, and start the next branch.

People often work for three weeks on one huge branch, then ask for a review of 2000 lines. Nobody can review that well, and the first comment might mean changing everything. Ask for a review every few days, when one screen works.

When you read your own PR before asking, go through the diff line by line. Look for leftover console.log lines, commented-out code, files you did not mean to change, and any line you cannot explain.

Words to recognise
branchpull requestcode reviewdiffreview commentmergefeedback

You have a plan. Now you build it, over a few weeks. You will not build it alone. After each piece, Mamun (or a mentor) reads your code and leaves comments. This is called a code review.

Think of a cricket net session. A coach does not watch you play a full match and then say "bad". He watches ten balls, fixes your grip, and you play ten more. Small pieces, quick feedback.

Work in small pieces. One screen, or one feature, at a time. For each piece, make a branch: a separate line of work, so main stays working.

git switch -c add-expense-screen
# build, test on your phone, commit as you go
git push -u origin add-expense-screen

On GitHub, open a pull request (PR) from that branch. A PR says "here is my change, please check it before it goes into main". The page shows the diff: every line you added (green) or removed (red).

Write a clear request. Say what the change does, how you tested it, and what you want checked. Add a screenshot. Then say where you are unsure. "I am not sure my total is right when a member is deleted" is the most useful sentence in any PR.

Use AI, and keep the laptop. AI can explain an error, suggest a fix or review your code before Mamun does. The rule from Phase 0 still holds: if you can't explain a line, it doesn't go in the PR. In a review, Mamun may point at any line and ask "why?". "AI wrote it" is not an answer. "It finds the member by id, because names can repeat" is.

Read feedback calmly. A comment is about the code, not about you. Reply to each one. Fix it, or say why you think it should stay. Push the fix to the same branch, and the PR updates itself. When it is approved, merge it, and start the next branch.

People often work for three weeks on one huge branch, then ask for a review of 2000 lines. Nobody can review that well, and the first comment might mean changing everything. Ask for a review every few days, when one screen works.

When you read your own PR before asking, go through the diff line by line. Look for leftover console.log lines, commented-out code, files you did not mean to change, and any line you cannot explain.

Words to recognise
branchpull requestcode reviewdiffreview commentmergefeedback