News for hackers. Stuff that matters.
Re:How to do a code review by gwd on Friday September 06, 2019 @12:24PM (#20897012)
> where developers have made the code more generic than it needs to be, or added functionality that isn’t presently needed by the system.

I agree with this when it's internal interfaces. When you have public interfaces that you expect to have to support in a backwards-compatible manner for (ideally) years in the future, it's worth taking some time to think about how people might want to extend it in the future.

Re:How to do a code review by alexhutcheson on Friday September 06, 2019 @12:34PM (#20897117)
Within a monorepo like most code at Google, there isn't as much of a bright line between public and internal interfaces. If you don't get a public interface quite right on the first try, but it still has <~100 call sites, it's really easy to just make the change and fix all the callers. If your library has become popular and has substantially more call sites, then it's hard but still doable to fix.

This assumes that the interface is a function or method call within a binary. If it's an RPC, then making changes is much trickier, since you can't assume that both sides of the call were built at the same commit. This requires a lot of thought to make sure any changes to your RPC messages are both backwards- and forwards-compatible.