How to do a code review, Part 2

Microsoft several years ago published a conversational article on their case study on code review as well as their own in-house code review tool CodeFlow.

1. Code Review Challenges: The article highlights several challenges associated with code reviews, including time constraints, difficulty in coordinating reviewers, lack of context, and limitations of traditional review methods like in-person meetings or email-based reviews.
2. Asynchronous Code Reviews: CodeFlow addresses the challenges by providing a platform for asynchronous code reviews. This allows developers to review and provide feedback on code changes at their own convenience, regardless of time zones or physical location.
3. Distributed Collaboration: CodeFlow enables distributed collaboration by providing a centralized platform where developers can review, comment, and track the progress of code reviews. It eliminates the need for manual coordination and facilitates efficient communication between reviewers and authors.
4. Code Quality Improvement: Code reviews play a crucial role in improving code quality. By involving multiple reviewers, CodeFlow helps identify defects, bugs, and design flaws early in the development process. This leads to better overall code quality and reduces the likelihood of introducing errors into the codebase.
5. Knowledge Sharing: CodeFlow promotes knowledge sharing among developers. Reviewers gain insights into different codebases and programming practices, fostering a culture of learning and continuous improvement. It also helps distribute knowledge across teams and reduces reliance on individual developers.
6. Iterative Review Process: CodeFlow supports an iterative review process where developers can address feedback, make changes, and have subsequent rounds of review. This promotes collaboration, allows for further refinement of code changes, and encourages constructive discussions between authors and reviewers.
7. Metrics and Insights: The article presents statistical data on CodeFlow's usage, including the number of code reviews conducted, average review duration, and the number of code changes accepted or rejected. These metrics provide insights into the effectiveness and efficiency of the code review process.

Check out part 1 of these series on code review.

How to do a code review, Part 1

Code review is a practical and important skill that truly distinguishes the highly experienced engineer. Knowing what are the common pitfalls, where to look for them, and how to understand someone else's code quickly is an invaluable skill to have. It is also a skill that is rarely taught in school. To really ramp up your programming skills, get out there and read other people's code. Reading high quality code is a good learning experience. Occasionally reading poorly written code is also insightful. What are the most common errors and where do you find them? Through code reviews, software engineers can spread knowledge through their teams as well as improve consistency and code quality. For the interviewee, you have to review your own code, so it helps to know what are the things you need to double check. One great way to evaluate a team's culture is to probe and understand their code review practices or lack thereof. Below, I will cover some of the best practices and provide a few pointers on where you can get started.

How to search for great programmers, Part 2

Aline Lerner of Trialpay recently posted statistics on an experiment about resume review. The conclusion was that recruiters, engineers, and just about everyone score resumes all over the place and therefore resumes have weak signal value. The claim was that the strongest signal in the resume was the number of typos. Although the study seems extensive, I think there are a number of weaknesses in the experimental design. One weakness was acknowledged: the ground truth is the author's own subjective evaluation of the candidates. Another weakness was how the survey questions were somewhat misleading in the first place. The questionnaire asks "would you interview this candidate" and yet this was compared with the ground truth of "will the candidate perform well on the job or technical interview". As I alluded to in an earlier post in this series, the role of a resume is to help filter for red flags and to guide the formal interview, not to determine whether a candidate is a star performer by itself. The fact of the matter is, a resume is a self-reported synopsis of a candidate's track record. To evaluate a candidate, I would think track records are important, as is potential.

How to search for great programmers, Part 1

photo by super-structure	via PhotoRee

A running theme these days is that Github is the new resume and a great source for learning. I am skeptical of these claims. If Github is the new resume, then it is one that is potentially even more difficult to evaluate than before and will greatly limit the candidate pool and not necessarily to a high quality one. The bigger question is what role should Github play in the hiring process. After all, many if not most of the famous hero programmers out there (e.g., Brian Kernighan, Herb Sutter, Alex Stepanov) do not have Github profiles. Linus Torvalds does, but he seems to be an exception. A Github profile is also difficult to evaluate. Do we consider only superficial metrics such as commit/contribution frequency or dive deep into a random project? Either of those options do not seem particularly attractive. At most, they will provide an imperfect measure for enthusiasm. It seems to me if code samples is what we are after, then we should ask for code samples. A real resume provides a highly condensed means to evaluate for relevant experience and education that can be evaluated in seconds.