<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/">
  <channel>
    <title>Code-Review on Jake Worth</title>
    <link>https://jakeworth.com/tags/code-review/</link>
    <description>Recent content in Code-Review on Jake Worth</description>
    <image>
      <title>Jake Worth</title>
      <url>https://jakeworth.com/twittercard.png</url>
      <link>https://jakeworth.com/twittercard.png</link>
    </image>
    <generator>Hugo -- 0.159.1</generator>
    <language>en-us</language>
    <lastBuildDate>Mon, 27 Apr 2026 16:06:20 -0400</lastBuildDate>
    <atom:link href="https://jakeworth.com/tags/code-review/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>On commenting and approving pull requests</title>
      <link>https://jakeworth.com/posts/on-commenting-and-approving-pull-requests/</link>
      <pubDate>Wed, 22 Apr 2026 11:06:20 -0400</pubDate>
      <guid>https://jakeworth.com/posts/on-commenting-and-approving-pull-requests/</guid>
      <description>&lt;p&gt;After reviewing a lot of pull requests, I&amp;rsquo;ve settled on a simple default: if my comments are all nitpicks, suggestions, questions, or non-blocking issues, I leave them and approve the PR at the same time.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Things I Check Before Opening a PR</title>
      <link>https://jakeworth.com/posts/things-i-check-before-opening-a-pr/</link>
      <pubDate>Sat, 07 Feb 2026 14:58:34 -0500</pubDate>
      <guid>https://jakeworth.com/posts/things-i-check-before-opening-a-pr/</guid>
      <description>&lt;p&gt;What is a programmer but a series of PRs (pull requests)? I optimize PRs to
introduce the best code I can, be easy to review, and document my work so I can
make sense of it in the future. Here are some things I always check before
opening a PR.&lt;/p&gt;</description>
    </item>
    <item>
      <title>How I Review Code, Part 2</title>
      <link>https://jakeworth.com/posts/how-i-review-code-pt-2/</link>
      <pubDate>Thu, 06 Jun 2024 00:00:00 +0000</pubDate>
      <guid>https://jakeworth.com/posts/how-i-review-code-pt-2/</guid>
      <description>&lt;p&gt;Reviewing code is tricky. When I&amp;rsquo;m doing it, I&amp;rsquo;m trying to achieve a few things
at once. In this post, I&amp;rsquo;d like to document the ways I try to add value via
code reviews.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Why Great PRs Are Great: Pull Requests Templates</title>
      <link>https://jakeworth.com/posts/pull-request-templates/</link>
      <pubDate>Mon, 14 Aug 2023 00:00:00 +0000</pubDate>
      <guid>https://jakeworth.com/posts/pull-request-templates/</guid>
      <description>&lt;p&gt;Have you ever seen a pull request that seems to completely explain itself? It&amp;rsquo;s
a real artifact. I don&amp;rsquo;t know the project, yet I understand it. How can we get
results like this on every pull request, from every developer on the team,
every time?&lt;/p&gt;</description>
    </item>
    <item>
      <title>Don&#39;t Ask for Advice; Ask for a Code Review</title>
      <link>https://jakeworth.com/posts/dont-ask-for-advice-ask-for-a-code-review/</link>
      <pubDate>Wed, 09 Aug 2023 00:00:00 +0000</pubDate>
      <guid>https://jakeworth.com/posts/dont-ask-for-advice-ask-for-a-code-review/</guid>
      <description>&lt;p&gt;Here&amp;rsquo;s some advice about programming I&amp;rsquo;ve found useful: &amp;ldquo;Don&amp;rsquo;t ask for advice; ask for a code review.&amp;rdquo; In this post, I&amp;rsquo;d like to explore what I think this adage means.&lt;/p&gt;</description>
    </item>
    <item>
      <title>How I Review Code</title>
      <link>https://jakeworth.com/posts/how-i-review-code/</link>
      <pubDate>Sun, 06 Mar 2022 00:00:00 +0000</pubDate>
      <guid>https://jakeworth.com/posts/how-i-review-code/</guid>
      <description>&lt;p&gt;Code reviews are important on many teams. Do them well, and your code ships
quickly and safely. Do them poorly, and your code ships slowly and riskily. I
try to contribute good code reviews. In this post, I&amp;rsquo;ll share my process.&lt;/p&gt;</description>
    </item>
    <item>
      <title>How and Why to Squash Your Pull Request</title>
      <link>https://jakeworth.com/posts/squash-your-pr/</link>
      <pubDate>Sun, 03 Jul 2016 00:00:00 +0000</pubDate>
      <guid>https://jakeworth.com/posts/squash-your-pr/</guid>
      <description>&lt;p&gt;Many pull requests go through a cycle: programmer opens pull request,
maintainer gives feedback, programmer makes changes, repeat until ready to
merge, maintainer merges. Prior to the merge, the pull request can be messy,
full of reverts, fixups, and WIP commits. In the end, those commits are noise.
We can tell a better story by squashing the branch.&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
