Review, Don’t Redo

Recursion is a funny thing. It’s like the code that’s calling the code is calling the code. Or, I mean, the function that invokes the function is the function. Wait, what? The function invokes itself. One might say. Well of course, but imagine you take a snapshot of the stack of your address space after a single recursive call. How did you get there?

Well, the function which invoked the function was the function. Sort of like calling yourself on the phone to tell yourself to call yourself on the phone? Anyways, I’m belaboring a point that there’s a funny sort of self-referential nature to recursion. In programming, there is at least one useful self-referential pattern: recursion.

Usually, though, when I think of self-reference philosophically, I tend to think of it as a destructive concept. For instance, think of the game of telephone. People sit in a circle and someone in the circle comes up with something to say, then says it to the person next to them. Then the person who just got the message turns to the person opposite them and says the thing to that person, and so on.

The silly game component is to complete the game by traversing the circle and ending up at the person besides the person who originally said the thing, and to compare the thing they hear to what was originally said. The philosophical thought experiment that comes to mind when I think of the game of telephone is related to a question of determining one’s values: how you decide wha’s good?

Well, it’s not uncommon for people to defer to other people to decide what they believe is good, especially in large group settings. There’s safety in numbers and a strong human impulse to optimize the potential for social connection. Often times, in social dynamics, people don’t even attest to their values until someone else has.

But there’s a self-referential problem here, right? If everyone deferred to everyone else to decide what was good then no one would know what was good because there would be nothing to ground a sense of good in any sort of concrete or innate quality. At some point, someone has to just decide what’s good or not, and then the people who defer to others to compose their value systems can follow suit.

Everyone deferring to everyone else means nothing ever becomes substantively true.

Self-reference in this context is destructive. It’s like answering a question by asking the person that asked you the question the question they asked you.

wth does that have to do with code review Spencer?

It has this do with code review. Code review shouldn’t be about software design (1). Why? Because someone’s already done the software design. If someone else has done the software design, and you try to do the software design at code review time, you may as well just redo the entirety of their work. If everyone did the software design, then who did the software design?

When it comes time to figure out why that strange corner case bug popped up, can anyone describe what they were thinking when they made the software that way?

Even less philosophically, doing design at code review time is problematic for other reasons. What’s going to happen if you try to redesign the software you see in code review is you’re going to disagree with the person who made the PR and, well, you’ll follow this switch statement:

switch (you and them):
    case (you have backbone and they have backbone):
        there is no progress made as you fundamentally
        disagree with one another, eventually you call your
        manager and force them to decide
    case (you have backbone and they don’t):
        you ignore their comments and merge your code,
        ignoring what might happen at performance review
        time
    case (they have backbone and you don’t):
        you throw away all your code and move
        on to a different project

As a wise person once said to me, it is “every way not the way”. It’s also an overstep. Design decisions are hard and have to be made under constraints that aren’t obvious to you unless you literally do the work yourself. It’s very easy to look at a design and say they’ve missed something and much harder to understand why it is the way it is and do it better.

Doing design at code review time also results in PRs with 50 – 100 comments and like 5 – 10 rounds of revisions, and very likely will sour relationships between peers (because it’s rude, drags people’s work out and might just make the code worse). What’s more, even if the design is flawed, are you teaching them something they can apply to their next project, or shouting at them about how l33t you are?

If they don’t organically come to understand why the improvements you’re suggesting are better themselves, you’re interfering with their professional development and wasting an opportunity to teach something you know to them. What’s more, you might just be wrong, even if you’re s3ni0r.

It’s easy as a software engineer to be an incorrigible nuisance. I’ve taken to generally only leaving feedback on code reviews when I know I can suggest the modification as code (like, literally, me writing the code in the comment) or about very specific things (like something in the documentation related to the way they’re using an API, or a stylistic thing with their use of language constructs).

Anyways, review don’t redo. If everyone else does everyone else’s design, did anyone do design?