{
  "author": {
    "name": "Dylan Fitzgerald",
    "url": "https://dylanfitzgerald.net/"
  },
  "blyg": "0.4",
  "changelog": [
    {
      "at": "2024-10-10T03:18:00Z",
      "note": "Imported from the Ctrl+Shift archive",
      "version": 1
    }
  ],
  "content_hash": "sha256:339f5f16c959062e137d6fe06d79524b2f8e99b7e77ee27790aabae1a04c4896",
  "content_html": "\u003ch1\u003eHigh-value reviews from your newest team members\u003c/h1\u003e\n\u003cfigure\u003e\u003cimg src=\"https://dylanfitzgerald.net/ox-hugo/daltoris_a_young_woman_sitting_at_a_computer_imagining_comple_8c1bf496-1c87-47c2-9fd4-94ecb8426c66_3.jpg\"\n\t\t\talt=\"A young womaning sitting at a computer imagining complex realities\" width=\"40%\"\u003e\n\u003c/figure\u003e\n\n\u003cp\u003eAbstracting is all fun and games till someone on your team writes a DSL without meaning to and in so doing makes onboarding new devs impossible. It’s hard for the author to see this—being too close to the code makes non-obvious things seem obvious: oh, you just call a self-registration function defined on the base class three levels of inheritance up in another file! Once someone’s got most or all of the structure of your team’s code loaded into their head, shifting complexity into it doesn’t appear to make things any harder than having a more complex function.\u003c/p\u003e\n\u003cp\u003eThe best way to find this complexity that’s been pushed from implementation into structure is to have someone else try to understand the code, and tell you what’s hard. And the person on your team best positioned to do this isn’t your longest-tenured or highest-paid engineer—it’s your newest.\u003c/p\u003e\n\u003cp\u003eThis is a peer review, yes—but it isn’t a Peer Review As We Typically Frame It. Most peer review’s purpose is to be a filter, preventing “bad” code from getting added into our expensive products. This isn’t without value, but it’s not what I’m talking about.\u003c/p\u003e\n\u003cp\u003eMy suggestion: have your newest folks try to explain to the author of a medium to large sized changeset how their code works. (I freely acknowledge this is not a \u003cem\u003efun\u003c/em\u003e task for the reviewer-to-be.) The value is in finding where they struggle—and helping clarify how you can make those areas easier to understand in the future.\u003c/p\u003e\n",
  "content_md": "# High-value reviews from your newest team members\n\n{{\u003c figure src=\"/ox-hugo/daltoris_a_young_woman_sitting_at_a_computer_imagining_comple_8c1bf496-1c87-47c2-9fd4-94ecb8426c66_3.jpg\" alt=\"A young womaning sitting at a computer imagining complex realities\" width=\"40%\" \u003e}}\n\nAbstracting is all fun and games till someone on your team writes a DSL without meaning to and in so doing makes onboarding new devs impossible. It’s hard for the author to see this—being too close to the code makes non-obvious things seem obvious: oh, you just call a self-registration function defined on the base class three levels of inheritance up in another file! Once someone’s got most or all of the structure of your team’s code loaded into their head, shifting complexity into it doesn’t appear to make things any harder than having a more complex function.\n\nThe best way to find this complexity that’s been pushed from implementation into structure is to have someone else try to understand the code, and tell you what’s hard. And the person on your team best positioned to do this isn’t your longest-tenured or highest-paid engineer—it’s your newest.\n\nThis is a peer review, yes—but it isn’t a Peer Review As We Typically Frame It. Most peer review’s purpose is to be a filter, preventing “bad” code from getting added into our expensive products. This isn’t without value, but it’s not what I’m talking about.\n\nMy suggestion: have your newest folks try to explain to the author of a medium to large sized changeset how their code works. (I freely acknowledge this is not a _fun_ task for the reviewer-to-be.) The value is in finding where they struggle—and helping clarify how you can make those areas easier to understand in the future.",
  "created": "2024-10-10T03:18:00Z",
  "id": "6qmt78p34nhen12fyj271qp2rb",
  "kind": "thread",
  "media": [],
  "origin": "https://dylanfitzgerald.net/blyg/",
  "page": "https://dylanfitzgerald.net/blog/high-value-reviews-from-your-newest-team-members/",
  "transclusions": [],
  "updated": "2024-10-10T03:18:00Z",
  "version": 1
}