The BrightRoll Hug, or Learning to Love Code Reviews

Coding at BrightRoll has been intense, and unlike anything I’ve ever done before.  I knew it would be hard and that I would learn a lot this summer.  What I wasn’t expecting was how much of a difference it would make to be a part of a team.

When you’re the only one working on a project, you don’t have to worry about trying to understand other people’s code, and you don’t have to worry about making sure other people can understand yours.  You also (theoretically) know how every part of the system works, since you’ve been working on it since the beginning.

But when you come up on an existing codebase and have to work together with the other engineers to make changes, that is a whole different story.  Now you have to spend time upfront getting to know a little bit about how everything works, though it’s going to be a long time before you understand everything.  Then, you have to get to know the specific team’s style of coding (BrightRoll: NO EXTRA WHITESPACE).  After a while, you can start writing, but you have to coordinate your work, so that no one steps on anyone else’s toes.

Also, you have to have periodic code reviews, so that every time someone makes a change, everyone knows what it was and why it had to happen.   Code reviews can come in many shapes and sizes, but in the end, it just means that at least one person reviews your code thoroughly before you check it in and push it out where real users can see it.

If this sounds like a lot of process, that’s because it is.  It takes a significant amount of time and energy to accomplish a level of harmony, and it’s not hard to screw it up.  But this is what makes large-scale projects possible.   It’s like have a team of artists working on one painting, or having many writers make on novel.  Things like that require organizing time.

They also require trust.

At BrightRoll, there are two types of code reviews.  There are individual reviews, where one experienced person sits down and checks things over, and group reviews, where the whole team goes into a room and projects the new code for all to see.

Both kinds freaked me out.

I was just not comfortable with showing my code to other people.  I was learning Ruby on Rails as I went along, so everything I had written came with a lot of help from Google, and I wasn’t entirely sure how it worked (Rails is full of magic), or whether I did it the right way.   I imagined that a code review would be like getting stabbed repeatedly with tiny swords.

So I stuck to individual code reviews for a couple weeks, from the least intimidating person I could find.

During those weeks, I went out to lunch every day with the team.  New people joined, and so there were many welcoming lunches with rounds of introductions.  My desk was moved to be near the center of engineering, where I heard and took part in daily discussions of the newest technology.  I quickly found out that everyone around me was a teddy bear inside, and started enjoying and looking forward to my time at work.  I started asking my neighbors for help interpreting code.  I started asking everyone how to become a real software engineer, and what their opinions were on the gaming industry, and what their thoughts were on entrepreneurship.

BrightRoll’s atmosphere forced me to become comfortable and happy – I couldn’t have stayed shy and nervous, even if I’d wanted to.  I’ll never forget that.

After a few rounds of fixes, Adolfo, my non-intimidating reviewer, declared that I was past making embarrassing programming mistakes and needed a group code review.  And I wasn’t freaked out anymore.  I looked forward to projecting my code up front.  And I was sincerely happy when people pointed out things that were wrong with it, because I knew that they were trying to build me up, not tear me down.

After tons of mistakes had been pointed out, someone in the group said, “So this is your first time using Rails?”

“Yeah,” I said, “And Ruby and JQuery and MySQL too.”

“Nice.”