I was surprised.

Pearl Chen
Nov 7, 2013 · 1 min read

I’ve been doing more code reviews at work these past few weeks and it’s interesting how most people cite “keeping bad code out of software” as the main reason for doing code reviews.

I’ve only done 2 so far in this current format and I find it really surprisingly how much I’m learning from doing them.

I see a dev implementing something that I initially built and sometimes they misuse the API or implement the feature incorrectly. Instead of thinking that they used it in the “wrong” way, I finding myself asking:

  • Could my documentation have been better for them?
  • Can I simplify this so it’s easier for someone else to implement?
  • Maybe I should add this other feature to make it easier for re-use?

But I never would have asked myself these question unless I saw someone unknowingly doing the opposite of what I expected them to do.


If you’re in a company that thinks that they don’t have the time for code reviews or that code reviews are only beneficial for the junior developers: they are sadly mistaken.

Because when you set out to build something, you are never going to ever get it perfect the first time. In order to learn how to make your code better, writing frameworks requires watching real people use the thing that you made — and what people do with always surprise you.

Coding & Culture

Stories about working in tech.

Pearl Chen

Written by

Technologist + Educator http://klab.ca

Coding & Culture

Stories about working in tech.

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade