Blog

Embracing Code Reviews

By Lisa Burgess on August 31, 2015

As a former freelance developer, the first time I learned about a “code review” was from a peer who worked at a Philadelphia-based web agency. She explained that she’d recently been given formal feedback from her team on some code she’d written for a big project. “So, tell me where you were going with this…”—that was the review comment, she told me, that had her almost in tears and questioning her value as a developer.

This peer was the amazingly talented Jana Veliskova (who is totally on board with me telling this story). I had just watched her move fearlessly forward in her career by taking full advantage of Girl Develop It classes, mentorship, and networking opportunities as she worked tenaciously to build her skill set. Within weeks of starting her new job at this agency, she was already giving presentations to her co-workers about tools and strategies she’d picked up along the course of her career.

I was startled by how intensely this comment affected her—and I did what I could to reassure her that she was exactly where she was supposed to be, and that not everyone can expect perfection 100% of the time.

Jana’s reaction to her code review was understandable, and very common among developers. The experience of putting your code on display can be a personal one; you’ve done hours of research and have maxed out your knowledge base to build something that makes you proud. Someone else coming along to point out flaws in implementing best practices, lack of efficiency, or failure to consider an obvious use case is the last thing that developers want or need to hear.

Or is it?


We always want to meet Web Developers who are interested in a growth and team-focused environment! Check out our Careers page.


Knowledge Sharing is at the Center of Our Field

During my time as a freelancer, it was difficult to come by opportunities to have my work examined by someone with more experience than me. The clients or companies I did contract work for were more interested in the product I was delivering than they were in the development of my skills. Questions like “is there a better way to do this next time?” usually remained unanswered. After learning that some of my peers were doing code reviews, I asked the tech lead of a project I was working on if I could have one, too. He said “sure,” but the opportunity never materialized.

As developers, we are given the privileges and responsibilities that come with being part of a highly-collaborative community grappling with a persistently evolving craft. As technology changes faster than the speed of light, and new ideas and methodologies outnumber the stars on a daily basis, we struggle to apply the knowledge we’ve accumulated and the systems we’ve accessed to solve a problem in real time.

If open knowledge sharing wasn’t at the heart of our field… well, I can’t even finish that sentence because I can’t even imagine it.

Peer Feedback Leads to Better Work

Humility is one of the strongest traits of a great developer. If we allow our confidence to hinge upon our own flawless delivery, we can feel unnecessary hurt and risk missing a valuable growth opportunity. The more we open ourselves up to new ways of thinking, draw from the experience of others, and question our own code, the more we increase our potency as problem solvers.

I recently had my first code review at Think Brownstone… and it wasn’t scary. I enjoyed two hours of undivided attention from a senior developer who helped me to identify the weaker areas in my code, and even suggested some refactoring that would ultimately bring the project I was working on to the level of organization and efficiency that we aspire to as a team.

During my review, I learned something new while feeling the support of a strong team of developers who hold each other up to the standards we’ve worked so hard to define. These standards are the result of thoughtful collaboration and a desire to harness emerging technology while retaining tried and true methodologies—all serving the end goal of delivering high quality products to our clients.

What I’ve learned is that we can embrace code reviews and think of them as a step in the process of becoming better developers. Also, we can transform any insecurity we feel into empathy to draw upon when we have the opportunity to review others’ work in the future.