Skip to content

Instantly share code, notes, and snippets.

@reidjs

reidjs/Pull Requests

Last active April 28, 2022 01:10
Show Gist options

  • Select an option

    Learn more about clone URLs
  • Save reidjs/4355dd58619ab4f2b26f2492ff73c08e to your computer and use it in GitHub Desktop.

Select an option

Learn more about clone URLs
Save reidjs/4355dd58619ab4f2b26f2492ff73c08e to your computer and use it in GitHub Desktop.
Download ZIP

Revisions

  1. reidjs revised this gist Sep 14, 2021. 1 changed file with 2 additions and 2 deletions.
    4 changes: 2 additions & 2 deletions Pull Requests
    View file
    Original file line number Diff line number Diff line change
    @@ -1,8 +1,8 @@
    It takes exponentially longer for a developer to review pull requests as they become more complex,
    this is a simple model of the relationship:
    ```

    t = k**n
    ```

    t: time to complete code review
    k: the number of files
    n: the number of changes per file
  2. reidjs revised this gist Sep 14, 2021. 1 changed file with 1 addition and 1 deletion.
    2 changes: 1 addition & 1 deletion Pull Requests
    View file
    Original file line number Diff line number Diff line change
    @@ -7,7 +7,7 @@ t: time to complete code review
    k: the number of files
    n: the number of changes per file

    This model demonstrates that smaller PRs are exponentially easier to review. For example:
    This model demonstrates that smaller PRs are much faster to review. For example:

    If you need to change 10 files and an average of 4 changes per file,
    it will take 10**4 or 10,000 developer-time units to review the PR
  3. reidjs revised this gist Sep 14, 2021. No changes.
  4. reidjs revised this gist Sep 14, 2021. 1 changed file with 2 additions and 2 deletions.
    4 changes: 2 additions & 2 deletions Pull Requests
    View file
    Original file line number Diff line number Diff line change
    @@ -1,13 +1,13 @@
    It takes exponentially longer for a developer to review pull requests as they become more complex,
    Below is a simple model of the relationship:
    this is a simple model of the relationship:
    ```
    t = k**n
    ```
    t: time to complete code review
    k: the number of files
    n: the number of changes per file

    Proof:
    This model demonstrates that smaller PRs are exponentially easier to review. For example:

    If you need to change 10 files and an average of 4 changes per file,
    it will take 10**4 or 10,000 developer-time units to review the PR
  5. reidjs revised this gist Sep 14, 2021. 1 changed file with 5 additions and 4 deletions.
    9 changes: 5 additions & 4 deletions Pull Requests
    View file
    Original file line number Diff line number Diff line change
    @@ -1,8 +1,9 @@
    If you accept that it takes exponentially longer for a developer to code review pull requests (PRs) the more complex they become,
    then you can describe the time it takes to review code using this equation:
    It takes exponentially longer for a developer to review pull requests as they become more complex,
    Below is a simple model of the relationship:
    ```
    k**n
    t = k**n
    ```
    t: time to complete code review
    k: the number of files
    n: the number of changes per file

    @@ -12,6 +13,6 @@ If you need to change 10 files and an average of 4 changes per file,
    it will take 10**4 or 10,000 developer-time units to review the PR

    If you can split that in half to 5 files, with an average of 4 changes per file,
    it will take 5**4 + 5**4 or 1,250 developer-time units to review the PR
    it will take (5**4 + 5**4) or 1,250 developer-time units to review the PR

    By splitting the PR in half, the time it takes to review it drops by nearly an order of magnitude (8x).
  6. reidjs created this gist Sep 13, 2021.
    17 changes: 17 additions & 0 deletions Pull Requests
    View file
    Original file line number Diff line number Diff line change
    @@ -0,0 +1,17 @@
    If you accept that it takes exponentially longer for a developer to code review pull requests (PRs) the more complex they become,
    then you can describe the time it takes to review code using this equation:
    ```
    k**n
    ```
    k: the number of files
    n: the number of changes per file

    Proof:

    If you need to change 10 files and an average of 4 changes per file,
    it will take 10**4 or 10,000 developer-time units to review the PR

    If you can split that in half to 5 files, with an average of 4 changes per file,
    it will take 5**4 + 5**4 or 1,250 developer-time units to review the PR

    By splitting the PR in half, the time it takes to review it drops by nearly an order of magnitude (8x).