Idea: CodeFeed
Non-blocking code review
“If we don’t review code before it’s integrated we’ll never review it.” Maybe. Maybe not, though.
The kerfuffle around code review continues:
Now, never mind that I wasn’t advocating any particular position, I was stating a fact about my emotional state. I got some productive comments along the lines of, “What could you mean by ‘non-blocking’?” Here’s an example of what I mean.
Imagine you have a scrolling ticker of news items describing what’s happening in your whole code base.
“Kent started editing foo.js that you modified yesterday.”
“The structure change you made last week is spreading to other systems.”
“Class Foo is now nearly identical to class Bar.”
You see these items from your own perspective of the code, things that do/will/should matter to you, aggregated to match your interest. Items contain text, diagrams, maybe animations.
Your engagement with the news defines how it is presented to you. Follow-up into the code? You’ll see more items like that. Comment? You’ll see more items like that. Ignore? You won’t see those items or they will be aggregated more.
Feeling
The feeling we’re trying to create here is that:
Senior engineers sustain the confidence that they know pretty much what is going on, even as the system and team scale.
Junior engineers have their curiosity piqued about adjacent parts of the system. They are also comforted knowing that they aren’t making changes solo. Someone is watching, but in a good way.
Engineering managers feel comfortable that they know what all is going on, without resorting to surveillance.
Process
If I was building CodeFeed, here’s how I’d do it. I’d hire 2 programmers with good writing skills to write a daily summary of activity on a popular, busy open source project. Analytics would keep track of how readers interacted with this manually-curated feed.
I’d encourage the programmers to write tools to make themselves more efficient, so they could produce a second newsletter, then a third.
Now, with a sense of how readers want to interact with the news, I’d sprinkle the AI Magic Fairy Dust on it to personalize & refine the feed.
Conclusion
There you have it—non-blocking code reviews that people will actually read. As I said at the beginning here, I’m not anti-code-review, I’m anti-waste. If we can get some of the desired benefits of code review at much less cost, we all benefit.
You'd have to combine it with some risk measures of the code. An automated scan that flags high risk changes. Example, potentially infinite recursion...that would get flagged. Any changes that are boilerplate just get automatically hidden from the feed. Formatting only changes, hide em. Someone committed a 2000 line file that was not autogenerated? Push it into the feed. And so forth
When I hear/read “If we don’t review code before it’s integrated we’ll never review it.”, I have to wonder if they really see any value to the code review process. If the only way to make them do the process is to make it a blocking operation, then it sound to me like those doing and managing the work lack motivation and cost justification to do it just for the alleged value of it. This strikes me as "crisis-driven management" -- getting things done by making them a crisis. And not by demonstrating their value.