Your first pull requests

Getting changes reviewed and merged safely, reviewing other people's code, and what to do when something breaks.

Small pull request

Also called PR, merge request, MR, CL, pull request

What: A change focused on one thing, small enough that a reviewer can understand it properly in one sitting.
Why: Small changes get faster, better reviews, are easier to test and are easy to revert if something goes wrong.

Watch out

Mixing a refactor, a formatting change and a feature in one pull request.

Pull request description

What: The text on a pull request that explains what changed, why, how it was tested and anything the reviewer should look at closely.
Why: Reviewers see the diff but not your reasoning. A clear description halves review time and becomes history for whoever reads it later.

MARKDOWN

## What
Add CSV export to the orders page.

## Why
Support asked for it (TICKET-412).

## How tested
Unit tests for the formatter; exported 3 real
orders on staging and opened them in a spreadsheet.

## Look closely at
The date formatting in `toCsvRow`.

Self-review

What: Reading your own diff in the review tool before asking anyone else, as if you were the reviewer.
Why: It catches debug code, typos, missing tests and unrelated changes, so the reviewer's time goes on things that matter.

Watch out

Requesting review on a draft full of leftover logs and commented-out code.

Testing your change

Also called CI, unit test, continuous integration

What: Adding or updating automated tests for what you changed, running them locally and making sure the CI checks pass before review.
Why: Tests show the change works and protect it from being broken later. Red CI is the first thing a reviewer notices.

Watch out

Deleting or skipping a failing test to get CI green without understanding why it failed.

Receiving code review

What: Reading comments as feedback on the code, answering each one, asking when a comment is unclear and pushing back politely with reasons when you disagree.
Why: Review is how teams share standards and how you learn fastest. How you respond builds trust as much as the code does.

Watch out

Taking comments as personal criticism, or silently changing everything a reviewer suggested without understanding why.

Reviewing other people's code

Also called code review

What: Reading a teammate's change for correctness, clarity and tests, and writing specific, kind comments that say whether each point blocks the merge.
Why: Juniors learn a lot by reviewing, and a good question on a senior's pull request is a real contribution.
Example: question (non-blocking): what happens here if the list is empty? I could not find a test for that case.

Watch out

Approving with "LGTM" without reading, because the author is more senior.

Safe deploys and rollback

Also called feature flag, rollback, revert, staging, roll back

What: Ways to release without breaking production: testing on staging, hiding new code behind a feature flag, releasing gradually and knowing how to revert.
Why: Everyone ships a bug eventually. Knowing how to undo a change quickly turns an incident into a small event.

Watch out

Deploying on Friday evening, or before leaving for the day, with no one watching the release.

Incidents and on-call as a junior

Also called on-call, incident, outage, pager

What: When production breaks, the team follows an incident process; juniors usually shadow on-call first, gather facts, communicate and escalate rather than fix alone.
Why: Knowing the process, the runbooks and who to call makes you useful and calm in an incident instead of frozen.

Watch out

Trying to fix a production problem alone and quietly instead of saying what you see in the incident channel.

Blameless postmortem

Also called postmortem, incident review, post-incident review

What: A written review after an incident that describes what happened, the impact, the causes and the fixes, focusing on systems rather than individuals.
Why: If you caused an incident, being open about it in a blameless review is how trust is kept, and how the system gets safer.

Watch out

Hiding your part in an incident, which is far worse for your reputation than the mistake itself.

Go deeper