<- all tokdocs
2026.10.22@danielleintech

The video says a 400-line PR "sits for two days"; a 3.3-million-pull-request study puts the median at 2,881 minutes, which is 48.0 hours

Coding
Watch on TikTok

View on TikTok ->

A 50.47-second vertical clip (ffprobe reports duration=50.466667 for both the container and the video stream, 50.455011 for the audio stream, against the rounded duration: 50 in metadata.json), 1080x1920, QuickTime/MOV container (format_name=mov,mp4,m4a,3gp,3g2,mj2), HEVC Main profile video in yuv420p at a constant 30/1 frame rate across 1,514 frames, HE-AACv2 audio at 44,100 Hz stereo across 1,090 frames, video bitrate 533,622 bps and audio bitrate 48,156 bps for an overall 588,634 bps, 3,713,302 bytes on disk, pulled as format bytevc1_1080p_588630-1. Posted at epoch 1792684140, which is 2026-10-22T15:49:00Z, by handle danielleintech (uploader_id 7420145965543703594) under the nickname "Danielle | Eng Leadership", credited to "original sound" by "Danielle | Eng Leadership", with a 180-character description that repeats the opening line verbatim and appends five tags: #engineeringmanager #techlead #codereview #engineeringleadership #devculture. At capture time (metadata.json mtime 2026-10-26T18:45:35Z, four days after posting) the counts read 1,213 views, 30 likes, 11 comments, 1 repost and 7 saves. I read 15 frames from tokdoc_frames at 2-second spacing: 001, 002, 003, 004, 005, 007, 009, 011, 013, 015, 017, 019, 021, 023 and 025, covering t=0 through t=48 seconds, against a 157-word transcript in 9 segments. The frames show one continuous unbroken talking-head shot with no cuts, no screen recording and no B-roll: a woman in dark rectangular glasses and a cream ribbed turtleneck, long brown hair, seated in front of black built-in bookshelves holding colored paperbacks, a small potted plant and a framed photo of a dog, with white textured ceiling and crown molding above. Frames 001 and 002 (t=0 and t=2) carry a peach title card reading "CODE REVIEW ·" over "HOT TAKE" in the top third plus a rounded tan-background caption reading "Where your team's velocity goes to die"; from frame 003 onward the title card is gone and captions render as white italic text with a black outline in the bottom third. The verbatim caption sequence I read is "and everyone's too polite to say it." (003, t=4), "One line change approved in 30 seconds," (004, t=6), "but the 400 line PR that actually needs eyes sits for two days" (005 at t=8 and still on screen at 007, t=12), "So that's not a discipline problem, though." (009, t=16), "And review isn't the thing you get to do when you're free." (011, t=20), "It's the thing that unblocks a human who's being stuck." (013, t=24), "So it comes first. And two changes that actually fix this." (015, t=28), "One is review before you open your own branch each morning." (017, t=32), "And two is max scrutiny to risk rubber stamp the config bump," (019, t=36), "and stop reviewing everything like it's equally dangerous." (021, t=40), "Follow for the parts of leading that nobody has trained you for." (023, t=44), and "And the full tech debt cheat sheet is at the link in my bio." (025, t=48). Because the clip is a single static shot whose caption changes land on transcript segment boundaries, 2-second sampling is sufficient here and I did not re-extract denser. No terminal, no pull request diff, no GitHub or Gerrit interface, no chart, no cited study and no URL appears in any frame I read; the "tech debt cheat sheet" and the bio link are named out loud at t=48 and never shown. The spoken argument runs in three moves: review latency is a prioritization failure rather than a discipline failure, review takes precedence because it unblocks another person, and two concrete changes follow, which are reviewing before opening your own branch each morning and matching review depth to the risk of the change. One divergence between the two text sources matters: the burned-in caption at t=36 reads "max scrutiny to risk", while Whisper transcribes "match scrutiny to risk" in the segment spanning 35.08 to 40.54 seconds, and "match" is the only reading that parses as English, so the platform caption is the corrupted one here rather than the transcript. On the Whisper end-of-audio check, the final segment runs 46.18 to 49.98 seconds against an audio stream of 50.455011 seconds, so every segment closes inside the real audio and nothing in this transcript is fabricated past the end.

The "two days" figure is the one number in the video that a large-scale measurement reproduces almost exactly

At 5.34 seconds the video says "One line change approved in 30 seconds, but the 400 line PR that actually needs eyes sits for two days because nobody wants to be the one to start it." The two-day figure reads like rhetoric. It is not.

Xunhui Zhang, Yue Yu, Tao Wang and Huaimin Wang assembled a dataset of 3,347,937 pull requests from 11,230 GitHub projects for "Pull Request Latency Explained: An Empirical Overview" (arXiv:2108.09946v1, 23 August 2021). Their Table 4 breaks median pull request latency in minutes across two conditions, whether the pull request drew comments and whether the contributor and the integrator were the same person. For the case that matches the video's scenario, a pull request from someone other than the merger that attracted review discussion, the reported median latency is 2,881 minutes. That is 48.02 hours, or two days to within a minute.

The same table gives the three other cells: 1,348 minutes (22.5 hours) when the contributor merges their own commented pull request, 311 minutes (5.2 hours) for an uncommented pull request from a different person, and 30 minutes when a developer opens and merges their own uncommented change. So the two-day wait the video describes is the median for exactly the kind of change it describes, a substantial pull request from a colleague that generates review conversation.

A second, narrower dataset lands lower. Yue Yu, Huaimin Wang, Vladimir Filkov, Premkumar Devanbu and Bogdan Vasilescu collected 103,284 pull requests from 40 Travis-CI projects for "Wait For It: Determinants of Pull Request Evaluation Latency on GitHub" (MSR 2015) and report a "median first comment time is 16min" and a "median 11.2h" closing time. Eleven hours is not two days. The gap between the two studies is scope: the 2015 paper samples the top ten projects per language on a CI service, which skews toward well-staffed, high-throughput repositories, while the 2021 paper spans 11,230 projects of every size. The video's figure sits at the population median, not at the healthy-project median.

"Approved in 30 seconds" and "sits for two days" are measurements of two different clocks

The rhetorical punch of the line at 5.34 seconds comes from placing 30 seconds beside two days, which implies a single scale on which one change gets 5,760 times the treatment of another. The two numbers do not share a scale. Thirty seconds is reviewer attention, the time a human spends reading a diff before clicking approve. Two days is calendar latency, the wall-clock interval between opening a pull request and closing it, nearly all of which is queue time during which no human is looking at anything. The video never separates them, and the separation changes what the viewer should conclude.

When you compare like to like, the ratio collapses. Caitlin Sadowski, Emma Söderberg, Luke Church, Michal Sipko and Alberto Bacchelli measured latency by change size inside Google for "Modern Code Review: A Case Study at Google" (ICSE-SEIP 2018, Gothenburg): "we find that developers have to wait for initial feedback on their change a median time of under an hour for small changes and about 5 hours for very large changes. The overall (all code sizes) median latency for the entire review process is under 4 hours." Small changes to very large changes is a roughly fivefold spread in time to first feedback, not a four-order-of-magnitude one.

The attention side has its own measurement. The same paper tracked interaction sessions in Google's Critique tool across five weeks starting October 2016 and found "that developers spend an average of 3.2 (median 2.6 hours a week) reviewing changes." Against Google's reported median of 4 changes reviewed per developer per week, 2.6 hours works out to roughly 40 minutes of attention per reviewed change, which is far above 30 seconds and well short of anything that would justify a two-day queue.

Size does drive latency, and the stronger lever is the one the video's first fix actually pulls

The video's implied mechanism is that a 400-line pull request waits because it is 400 lines. That is directionally supported and incompletely stated.

Yu and colleagues list their findings as bullets in the introduction of "Wait For It": "the presence of CI is a strong positive predictor", "the number of comments is the best single predictor of the latency", and "as expected, the size of a pull request (lines added, commits) is a positive, strong predictor." Their regression results section adds that "Pull request churn, size, and length of discussion, all highly significant, remain the most prominent predictors, together explaining 67% of the variance explained." Their conclusion states it plainly: "Naturally, the size of the pull request matters: the shorter it is the faster it will be reviewed."

So size matters, and it is beaten by discussion volume. The 2021 Zhang paper sharpens this further. Its abstract reports that "the first response time of the reviewer is most important when there exist comments", and its results section finds that for commented pull requests, "first response time (row 28), num comments (row 29), num code comments (row 23), hash tag (row 24) and prev pullreqs (row 4) rank the top 5, explaining 95.4% of the total variance."

First response time is the single largest measured determinant of how long a pull request waits. The video's first fix, reviewing before you open your own branch each morning, is a direct intervention on first response time. The video arrives at the right lever without naming the evidence for it, and it attributes the delay to the wrong variable on the way there.

Sadowski and colleagues reach a compatible conclusion from the literature they survey: "the number of useful comments decreases [11, 14] and the review latency increases [8, 24] as the size of the change increases. Size also influences developers' perception of the code review process; a survey of Mozilla contributors found that developers feel that size-related factors have the greatest effect on review latency [26]."

Google's published rule is one business day, and it tells reviewers not to interrupt a focused task

At 29.04 seconds the video says "One is review before you open your own branch each morning." Google's public engineering practices guide reaches a similar place through a looser rule.

The "Speed of Code Reviews" page states the commitment the video is arguing for: "At Google, we optimize for the speed at which a team of developers can produce a product together, as opposed to optimizing for the speed at which an individual developer can write code." That is the same claim the video makes at 23.00 seconds, "It's the thing that unblocks a human who's being stuck."

The operational rule, though, is a ceiling rather than a morning ritual: "One business day is the maximum time it should take to respond to a code review request (i.e., first thing the next morning)." And the page includes an explicit carve-out that the video's phrasing leaves out: "If you are not in the middle of a focused task, you should do a code review shortly after it comes in", and if you are mid-task, "wait for a break point in your work before you respond to a request for review." The page also narrows what is being promised: "It is the response time that we are concerned with, as opposed to how long it takes a CL to get through the whole review and be submitted."

Google's version permits a reviewer to finish a focused block before turning to the queue, provided the response still lands within one business day. The video's version removes that option and fixes the slot at the start of the day. Both target first response time, which the latency research identifies as the dominant variable, so the video's rule is a defensible tightening of a documented practice rather than a restatement of one.

"Rubber stamp the config bump" has survey support at Google; "rubber stamp" is the video's word, not anyone's guidance

At 35.08 seconds the video says "match scrutiny to risk, rubber stamp the config bump, but go deep on the auth change and stop reviewing everything like it's equally dangerous." The frame at t=36 renders this caption as "And two is max scrutiny to risk rubber stamp the config bump," which is a platform caption error on "match" rather than a Whisper artifact.

The underlying observation has direct primary support. Sadowski and colleagues surveyed Google developers on individual reviews and found that of the eight respondents who described the comments on their change as unhelpful, "3 provided more detail, stating that the changes under review were small configuration changes for which code review had less impact. Only 2 respondents said the comments had found a bug." Google engineers themselves identified configuration changes as the category where review effort buys the least.

The second half also has support. Google's "What to look for in a code review" page tiers by reviewer qualification rather than by review depth, specifying that "complex issues such as privacy, security, concurrency, accessibility, internationalization, etc." require "qualified" reviewers, and singling out user-facing behavior and parallel programming as the cases that warrant checking functionality closely.

No primary source I fetched endorses rubber stamping. Google's standard runs in the other direction on the floor, not on the ceiling: "In general, reviewers should favor approving a CL once it is in a state where it definitely improves the overall code health of the system being worked on, even if the CL isn't perfect", alongside the hard limit "Don't accept CLs that degrade the code health of the system." The documented practice is to stop demanding polish, not to stop reading. The distinction matters for configuration changes specifically, since a config bump is one of the few change types that can reach production without touching compiled code paths or test coverage.

The "400 line PR" sits exactly at the ceiling SmartBear's Cisco study identified

The video picked 400 lines as its example of a pull request "that actually needs eyes." The number is not arbitrary in the code review literature, and the video does not say why.

SmartBear's published write-up of its case study of a Cisco Systems programming team states that "developers should review no more than 200 to 400 lines of code (LOC) at a time", that "a review of 200-400 LOC over 60 to 90 minutes should yield 70-90% defect discovery", and that there is a "significant drop in defect density at rates faster than 500 LOC per hour." Four hundred lines is the top of the range where a single sitting still finds most of what is there.

Google's own guidance puts the threshold lower. The "Small CLs" page says "100 lines is usually a reasonable size for a CL, and 1000 lines is usually too large, but it's up to the judgment of your reviewer", and adds a shape qualifier: "A 200-line change in one file might be okay, but spread across 50 files it would usually be too large." The same page explains why small changes clear faster, saying they are "Reviewed more quickly" and "Reviewed more thoroughly", because on "large changes, reviewers and authors tend to get frustrated by large volumes of detailed commentary shifting back and forth, sometimes to the point where important points get missed or dropped."

Google's measured distribution shows how far 400 lines is from normal practice there. Sadowski and colleagues report that "over 35% of the changes under consideration modify only a single file and about 90% modify fewer than 10 files. Over 10% of changes modify only a single line of code, and the median number of lines modified is 24." A 400-line pull request is roughly seventeen times the median Google change. The video treats it as the ordinary case that deserves attention. In the one large industrial dataset with published size statistics, it is an outlier that the authoring practice is designed to prevent.

Key Takeaways

  • Verified: The video's claim at 5.34 s that a substantial pull request "sits for two days" matches Zhang et al.'s Table 4 median of 2,881 minutes (48.02 hours) for commented pull requests where the contributor and integrator differ, measured across 3,347,937 pull requests in 11,230 GitHub projects.
  • Context: A narrower 2015 dataset of 103,284 pull requests from 40 CI-using projects reports a median closing time of 11.2 hours and a median first comment at 16 minutes, so two days is the population median rather than the well-run-project median.
  • Clarification: The line "One line change approved in 30 seconds, but the 400 line PR ... sits for two days" compares reviewer attention time against calendar queue time. The two quantities are measured on different clocks, and the sentence invites a 5,760x reading that no source supports.
  • Partial correction: On a like-for-like comparison, Google's measured spread between small and very large changes is a median of under one hour to first feedback versus about five hours, roughly fivefold. Google's measured reviewer effort is a median of 2.6 hours per week across a median of 4 reviewed changes, which is around 40 minutes per change rather than 30 seconds.
  • Partial correction: The video attributes the delay to pull request size. Yu et al. find that "the number of comments is the best single predictor of the latency" with size a strong secondary predictor, and Zhang et al. find first response time ranks first among all factors for commented pull requests. The video's own first fix targets first response time, which is the stronger lever than the one it names.
  • Clarification: The video's rule "review before you open your own branch each morning" is stricter than Google's published rule, which sets one business day as a maximum and explicitly permits waiting "for a break point in your work" rather than interrupting a focused task.
  • Correction: The burned-in TikTok caption at t=36 s reads "max scrutiny to risk." The spoken words are "match scrutiny to risk," which the Whisper transcript captures correctly. The platform caption is the corrupted text here, not the transcript.
  • Verified: The video's "rubber stamp the config bump" instinct matches Google survey data, where 3 of the 8 respondents who called review comments unhelpful attributed this to "small configuration changes for which code review had less impact," and only 2 of 44 respondents reported that comments found a bug.
  • Clarification: No source I fetched endorses rubber stamping. Google's guidance lowers the approval bar ("even if the CL isn't perfect") while holding a hard floor ("Don't accept CLs that degrade the code health of the system"), and tiers by reviewer qualification for security, privacy and concurrency rather than by review depth.
  • Context: Four hundred lines is the top of SmartBear's recommended 200 to 400 LOC review range and roughly seventeen times Google's measured median change size of 24 modified lines.
  • Unverified: The "full tech debt cheat sheet is at the link in my bio" claim at 46.18 s. The TikTok profile page at tiktok.com/@danielleintech returned only the generic page title through WebFetch, with no bio text or link, so I could not confirm the resource exists or what it contains. No URL appears in any frame I read.
  • Context: The clip shows no evidence of its own. Across all 15 frames there is no diff, no pull request interface, no dashboard and no cited study. Every number in it is asserted from a static talking-head shot.

Resources

Published October 22, 2026. Writeup generated from a favorited TikTok.