Thanks for posting this Sam -- code review is one of the best parts of our
engineering culture, I'll definitely watch this when I get a chance.

-Toby

On Mon, Jun 29, 2015 at 7:59 AM, Sam Smith <samsm...@wikimedia.org> wrote:

> Hey y'all,
>
> I watch a lot of talks in my downtime. I even post the ones I like to a
> Tumblr… sometimes [0]. I felt like sharing Derek Prior's "Implementing a
> Strong Code Review Culture" from RailsConf 2015 in particular because it's
> relevant to the conversations that the Reading Web team are having around
> process and quality. You can watch the talk on YouTube [1] and, if you're
> keen, you can read the paper that's referenced over at Microsoft Research
> [2].
>
> I particularly like the challenge of providing two paragraphs of context
> in a commit message – to introduce the problem and your solution – and
> trying to overcome negativity bias in written communication* by offering
> compliments whenever possible and asking, not telling, while providing
> critical feedback.
>
> I hope you enjoy the talk as much as I did.
>
> –Sam
>
> [0] http://sometalks.tumblr.com/
> [1] https://www.youtube.com/watch?v=PJjmw9TRB7s
> [2] http://research.microsoft.com/apps/pubs/default.aspx?id=180283
>
> * The speaker said "research has shown" but I didn't see a citation
>
> *Notes (width added emphasis)*
>
>    - Code review isn't for catching bugs
>    - "Expectations, Outcomes, and Challenges of Modern Code Review"
>    - Chief benefits of code review:
>       - Knowledge transfer
>       - Increased team awareness
>       - Finding alternative solutions
>    - Code review is "the discipline of explaining your code to your peers"
>    - Process is more important than the result
>    - Goes on to define code review as "the discipline of discussing your
>    code with your peers"
>    - If we get better at code review, then we'll get better at
>    communicating technically as a team
>
> Rules of Engagement
>
>    - As an author, provide context
>
>
>    - "If content is king, then context is God"
>       - *In a pull request (patch set) the code is the content and the
>       commit message is the context*
>       - Provide sufficient context - bring the reviewer up to speed with
>       what you've been doing in the past X hours
>       - *Challenge: provide at least two paragraphs of context in your
>       commit message*
>       - This additional context lives on in the commit history whereas
>       links to issue trackers might not
>
>
>    - As a reviewer, ask questions rather than making demands
>       - Research has shown that there's a negativity bias in written
>       communication. *Offer compliments whenever you can*
>       - *When you need to provide critical feedback, ask, don't tell*,
>       e.g. "extract a service to reduce some of this duplication" could be
>       formulated as "what do you think about extracting a service to reduce 
> some
>       of this duplication?"
>          - "Did you consider?", "can you clarify?"
>          - "Why didn't you just..." is framed negatively and includes the
>          word just
>       - Use the Socratic method: asking and answering questions to
>       stimulate critical thinking and to illuminate ideas
>
> Insist on high quality reviews, but agree to disagree
>
>    - Conflict is good. *Conflict drives a higher standard of coding
>    provided there's healthy debate*
>    - Everyone has a minimum bar to entry for quality. Once that bar is
>    met, then everything else is a trade-off
>    - Reasonable people disagree all the time
>    - Review what's important to you
>    - SRP (Single Responsibility Principle) (the S from SOLID)
>       - Naming
>       - Complexity
>       - Test Coverage
>       - ... (whatever else you're comfortable in giving feedback on)
>
>
>    - What about style?
>       - Style is important
>       - "People who received style comments on their code perceived that
>       review negatively"
>       - Adopt a styleguide
>
>
> Benefits of a Strong Code Review Culture
>
>    - Better code
>    - Better developers through constant knowledge transfer
>    - Team ownership of code, which leads to fewer silos
>    - Healthy debate
>
>
> _______________________________________________
> Mobile-l mailing list
> Mobile-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/mobile-l
>
>
_______________________________________________
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

Reply via email to