The Case of Review Request Timing
A review request was sent at 5:47pm. The reviewer logs off at 6. The sender knows this.
SEARCH HISTORY RECONSTRUCTION
The following is reconstructed from the subject's browser and message history on a Thursday afternoon. It is presented without commentary, which is not the same as without implication.
3:18pm
"review request best practices"
3:31pm
"how early to send PR before end of day"
3:47pm No search. Work being done. This is the longest uninterrupted work period in the log.
4:12pm
"how long should code review take"
"are engineers required to review same day"
The governing rule: a review request timing may expand beyond its purpose if expansion can still be described as alignment.
4:34pm
"what time do most engineers check pull requests"
The answer to this question does not change the work. The work has been in a reviewable state since approximately 3:47pm. The review request has not been sent.
5:12pm
"is it bad to send code review late afternoon"
5:31pm No search. A final check. The code is correct. It was correct at 3:47pm.
5:47pm Review request sent.
5:47pm is late enough that no immediate response is expected, which means the work has been submitted without the accompanying anxiety of waiting for the response. The reviewer's calendar shows two morning meetings and a known tendency to do review work between 10 and noon.
The review request has been sent. It will not be reviewed tonight. Tonight, this is fine.
The review request timing creates visible motion without changing the underlying task. The task is complete. The completion has been filed at 5:47pm, which means it is technically tomorrow's problem to acknowledge.
This is a known and widely practiced protocol.
Tomorrow: two comments, one suggestion, and a request for a small clarification that could have been written in the description but was not because the description was written at 5:46pm.