Google: How to do a code review

Google is sharing “How to do a code review” as part of its engineering practices. Unlike many similar guides online, I find this document to be a lot more comprehensive. It covers both the technical bits of the process, as well as suggestions that improve overall team communications and efficiency.

A particular type of complexity is over-engineering, where developers have made the code more generic than it needs to be, or added functionality that isn’t presently needed by the system. Reviewers should be especially vigilant about over-engineering. Encourage developers to solve the problem they know needs to be solved now, not the problem that the developer speculates mightneed to be solved in the future. The future problem should be solved once it arrives and you can see its actual shape and requirements in the physical universe.

Perl 6 re-branding

Curtis “Ovid” Poe, the author of the book “Beginning Perl” and long-time Perl Monk, has this excellent post on the re-branding discussion of Perl 6.

Even though I’m not writing much Perl code these days, I have to admit that the whole Perl 6 thing has been going for years now and I’m one of those many people who were confused by it. In my opinion, Perl 6 is not a continuation of Perl 5 as a version bump (like in Python or PHP), but it is a different language. And as a different language, it should have a different name.

Of the ones mentioned in the blog post, I like the “Raku” the best. But given the negative connotation in some countries, cultures, and languages, “Camelia” seems like a better option.

Regardless of the alternative names, I want the change from “Perl 6” to anything else the sooner, the better.