First work
Asking for Review
Who you ask to review determines what the review finds, and the obvious choice is almost never the person whose name is on the thing you changed.
What the people on this page had to find out, and where from
That the test suite takes forty minutes
worked out3Nobody mentions this until you are waiting for it
That deployment happens on Tuesdays and Thursdays
told3Volunteered by a reviewer who assumed you knew
two things you had to know · one of them somebody told you · the median arrived in week 3 · the other one you went and got
Two things learned from one small piece of work, neither of which would have come from any amount of reading.
Remote onboarding becomes easier to improve when questions are supported by evidence; teams can visit the Monitask product page for a practical reference on time, activity, projects, and reports.
For additional context beyond this collection, see the material published by Totaljobs.
Who reviewed the first six pieces of work, and how they were chosen
Introduced, and needed · 4
- The colleague two years in — met in week 1; needed in week 3. Noticed from who answered in the channel
- The person who showed you the system — met in before you started; needed in week 3
- Your own manager — met in before you started; needed in week 4
- The designer on the adjacent product — met in week 2; needed in week 7
Needed, and never introduced · 2
- The person who runs the release — needed in week 5. Found by reading the channel history
- Whoever wrote the component originally — needed in week 9. Found by reading the commit log
six people · four you were introduced to · six you actually needed · two you had to find yourself
Six people, and four of your first six reviews went to one of them. Two of the people who should have reviewed something were never asked, and both were findable in the history of the thing being changed. One person's own first quarter.
Who reviews your work decides what the review finds. The default — ask the person who is friendliest, or your manager, or whoever is nearest — produces a review that misses the thing that matters.
Choosing a reviewer
The question to ask is not who is available. It is who would be annoyed if this were wrong.
Who would notice if I got this wrong, and who would have to deal with it?
That has a findable answer, and it is almost always somebody whose name is in the history of the thing you have changed.
| What you changed | Who should see it |
|---|---|
| A component somebody else wrote | Whoever wrote it, by the commit log |
| Anything touching a release | Whoever runs releases |
| Anything that changes an interface | Whoever consumes it |
| A document somebody owns | The owner, before anybody else |
Not your manager
In the panel above, one of six reviews went to the manager and the note says it should not have.
Managers are frequently not the best reviewers of the detail, they are the slowest to get to it, and routing your work through them establishes a pattern in which their approval is what makes your work finished. That pattern is hard to leave.
Your manager wants to know what you are doing and usually does not want to be in the loop on every change. The distinction is covered in the note on who to go to for what.
Asking in a way that gets a good review
A bare request produces a cursory read. Three sentences produce a real one.
Could you look at this? It changes how the retry limit is applied — I have followed the pattern in the import job but I am not sure the back-off is right for this case. The tests pass but I have not been able to reproduce the original failure.
What you changed, what you are unsure about, and what you could not verify. The second and third sentences direct the reviewer's attention to exactly where it is useful, and they also tell them you have thought about it.
Receiving the review
Three rules, and the third is the one that is hard.
Do not explain why you did it that way before understanding the comment. Most review comments that feel like misunderstandings are not.
Fix the small things without discussion. A comment about naming does not need a reply beyond the change.
Ask about the ones you disagree with, once, as a question.
I had done it that way because of the staging case — does that still work with your suggestion, or am I missing something?
If you are right, that gets established without anybody being contradicted. If you are wrong, you find out cheaply.
Too many comments
Your first review may come back with fifteen comments. This is normal and it is not a verdict.
Most of them will be conventions you had no way of knowing. A few will be real. None of them is a statement about whether you should have been hired, and the reviewer has almost certainly forgotten the whole thing by the next morning.
What is worth doing is noticing which comments are conventions and writing those down. The same fifteen comments arriving on your third piece of work would be a different matter, and the way to avoid that is a list rather than an intention.
The reviewer you did not ask for
Occasionally somebody who was not asked will comment on your work.
This is almost always good news. It means somebody with an interest has seen it, and it tells you who that is — which is information you would otherwise have had to go and find.
Add them to your list of people.
Reviewing somebody else's work
In the second month you will be asked to review something, and it is worth saying how to do it, because new people habitually do it badly in one specific way.
They comment on everything they notice, in order, at equal weight. The result is twenty observations in which the one that matters is indistinguishable from the one about a variable name.
Three habits fix it. Say at the top what you think overall. Mark which comments are important and which are preferences. And ask rather than assert about anything you may not have the context for, which in month two is most things.
Looks right to me overall. One thing I am not sure about: the retry in the second block — does that interact with the back-off, or am I misreading it? The rest is just naming and you can ignore it.