What I learn from 013 talk: Code Review Matters and Manners by Trisha Gee and Maria Khalusova

    I watched an very interesting talk "Code Review Matters and Manners" by Trisha Gee and Maria Khalusova.
    A code review is a  process of  source code verification to check is code does what is supposed to do and is it meet criteria set by rules (acceptance criteria, quality and so on)
Code review is an important technique,because:

1. It helps me as developer to :

• write better code
• verify did I understand acceptance criteria correctly. 

2. It helps code base to:

• have better quality
• to be consistent and
• to follow agreed  approach and practices
• increase confidence to other stakeholders (other developers, QA  and so on ) that code does what is suppose to do .

    In my opinion code review is very useful for above reasons. From my experience there is only one problem. A human factor and way how feedback is given. In my little work experience, it happens once when when I was annoyed by given feedback. Problem was with feedback that was given by person who behave like princess Goggle, where they are maniac about give as much as negative feedback as possible. Even for a minor detail and pretend this is always better. In practice large amount of time on detail that ... does not matter from functionality point of view.

This talks covers how to do code review and how to give feedback.

From this talk I learn ( re-learn or remind myself) about code review that:

I should focus on:

• Functionality :
• Is it doing what is suppose to do ?
• Is meet acceptance criteria and non-functional  requirements ?
• Code usability:
• Readability
• Maintainability
• Extensibility

We  should NOT focus on little annoying things that can be automated . Personally I found this kind of things annoy people rather than helps.

Code review is too late for design discussion and suggestion like:

• Is it in right place?
• Is it use right data structure , pattern ?
• is code is overly complex or over-engineered?
• Is use existing library or introduce new dependencies ?

About Give Feedback I learn that:

• You should have some code review manners rules written somewhere, where you should include things like:
• Discuss changes, not people
• Be specific
• Suggest alternatives.
• Don't be rude and don't offend people (directly or indirectly).
• Example of offend people indirectly is by using words like obviously ,simply.
• Refer to code not person This code not your code.
• and so on.

    I read somewhere recently that "Learning how to deliver negative feedback effectively is crucial." I think it is worth to add it is important to decode useful bits from feedback. As was told by Maria during talk we should "be grateful for it and try to decode what person mean as written words do not reflect real intention". I agree with this. It is specially visible when you working in international team where people come from different  work cultures and they may have a language barrier when communicate.

   It is important to give feedback that focus on improve code based on agreed standards without blame or attack directly or indirectly person, because in the end our goal is to deliver good enough code that deliver value to product.

    I have a lot to improve with my feedback . I need use better and more accurate vocabulary and reduce amount of sarcasm as I am very sarcastic person.

On side note. In order to write better code I am trying do code review in few ways.

• I use IDE  (IntelliJ IDEA has awesome inspector feature) , Sonar and  plugins like Checkstyle and Findbugs 
• I ask my colleague to double check my code (walktrough style) 
• At work we are doing code review in real time during pair programming.

That's all.

Trisha Gee presence on Internet Universe

Twitter: https://twitter.com/trisha_gee

Github: trishagee.github.io

Maria Khalusova presence on Internet Universe

https://twitter.com/mariakhalusova

You can watch this talk here:
https://vimeo.com/182087729