High-value reviews from your newest team members

Abstracting 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.

The 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.

This 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.

My 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.