Honest or nice

We have a lot of conversations how we could do better. Deliver more functionality and prettier UI, cause fewer bugs, have more fun while we put in more hours.  Write better code, and pay back the technical debt.

At 200OK web professional's conference we were talking about code review – the part of software development process where developers and architects get together to consider other people’s code with the purpose of offering critique.

Having one’s code subject to review is terrifying for many people, and liberating for others.  It is also necessary, for most of the code outside of personal projects.  But how we are going about doing the review can make a huge difference for all involved.

There comes a scary idea of being nice to the people one works with. Genuinely, authentically nice – actually wish them to be successful, be willing to put effort in helping them, and talking about that.
Here are some suggestions:

• Start code reviews with saying to your fellow developers that the work they have done toward the team’s goal is noticed and appreciated.
• Call out good code – clearly expressed logic, fitting patterns, relevant abstractions, meaningful naming.   
• Notice good intentions, as expressed in code, even if the result is less than perfect. That includes error handling, code broken down into smaller modules, attempts at unit tests.  
• Finally, suggest changes as you would to a very senior, very experienced colleague – share knowledge while acknowledging their wisdom and understanding.  Everyone needs to learn, and everyone deserves to learn in a respectful, cooperative environment. 

Being actively and explicitly nice, yet honest, to one’s teammates does a few interesting things to overall team dynamic. More people speak up and offer ideas. Jerks become more visible. More conflict bubbles up and out, and leads to a healthy discussion.

It may even lead to delivering more value, while enjoying working together more.