We all know that rubber duck is programmer’s best friend (it was also proven that such duck should be yellow for maximum effect). Not surprisingly I have also a yellow toy on my desk. But it is not a duck. It is a little yellow human-like figure.

Usually it sits and waits for me to start explaining some code. It waits patiently till I get to the aha! moment. Sometimes it waits long. But it never gets bored. From time to time I can see it’s smile widens when I explain the nuances of my-oh-so-perfect-and-surely-working code.

2015_09_yellow_static

But that is something which every rubber duck can do for you. My yellow friend has one hidden superpower which makes it much more useful. Look at the next image. Awesome, isn’t it?!

2015_09_yellow_hold

See? When I take my laptop home my yellow friend makes sure next time I come to the office I won’t have to dive under my desk to catch the cables. Cool, isn’t it?

Code reviews. Very helpful if done right, completely useless if done recklessly.

Below you will find a mindmap of “code review” (using Xmind). I simply sat down and tried to gather everything related to code reviews. Hopefully you will find some food for thought here.

2012_code_reviews

Some comments:

  • I knew one team lead (hello Marcin! 🙂 who had a very nice system of publishing code reviews by email to project’s mailing list. He believed (and had some good results to support this belief) that by doing such “public” code reviews he educates the whole team, and not only the author of the particular code. It worked for him and his team pretty well!
  • Marking code with TODO and FIXME during the review works pretty well for me. Nope, I haven’t used gerrit or any other tool like this yet.
  • IMHO code review should be a part of Definition of Done – no task is finished until someone else checked the code.
  • I don’t like the idea of team lead doing code reviews for the whole team. He has probably no time for this. The other thing is that some people find it hard to discuss with your “boss” (so they will follow blindly what the reviewer says). I like much more the idea of peer reviews. Even if some junior guys are not capable of performing code reviews properly (at least from the very beginning).
  • There is a great discussion regarding code reviews here.