On Code Reviews - Part 1 of 3

I've been pondering writing about this topic for a while and never really had the time to corral my thoughts and write it up.

Until I flew to GHC and had time at the airport and on the plane :).

This is not an exhaustive coverage of code reviews and is meant as a basic understanding and guideline for engineers.

It amazes me how many engineers (both young and old) still don't know much about code reviews and I have encountered some who have been working for several decades and have never had to do a code review (begs the question what sort of architecture/design/implementation have they produced?).

Some, usually the latter category, are vehemently opposed to having their code "poked" at by others and believe that they are entitled to writing/designing whatever they choose regardless of what others might think.  Generally, one tends to avoid working with such engineers, but, they do seem to pop up rather alarmingly frequently.

So, in short, code reviews are essential and all good software (and hardware interface engineers, if applicable) perform them religiously.

NOTE: A basic requirement for code reviews is to "Check your ego at the door".  Your work is going to be reviewed/dissected and comments will arise that will not be easy to digest.  This is a good thing.
A code review is not about you, it's about the code/product quality.  And you won't be the only one  - everyone has to go through it.  So, deal with it graciously, be thankful that you have good reviewers and that you are, eventually, going to become a better engineer because of it.

What is a code review?

A code review is quite literally a reading/understanding and critical thinking process that is applied to programs/code that either needs to be shipped as part of a product or used internally by developers to build products.   Written and/or oral feedback is given to the author on whatever is being reviewed so that s/he can incorporate the feedback and improve things before checking in the code into mainline or a branch.

By no means is this an exact method for eliminating all errors in a given piece of software, but, it is reasonably effective (if used properly) at identifying errors, potential errors and, eventually, providing quantitative and qualitative feedback to the author about her/his technical approach and implementation.

The review might also include architecture/design of the component that is being reviewed as a background for the reviewers, particularly if the code is a critical path in the product and/or interfaces with other critical paths in the product.

There are a whole host of other definitions for a code review, but, this is the one that makes most sense to me.

Why do we need code reviews?

Code reviews are and have been one of the few ways of mitigating programming and design risk associated with a product - early in the development cycle.  Usually, it is a human process to understand and evaluate architecture, design and programming paradigms as well as algorithms in order to visually and conceptually understand how a given piece of a product works and is implemented.

In the end, code reviews help a developer/engineer become a better developer/engineer and, also, establishes technical standards within a group of developers/engineers, resulting in a better product in the end.  It also provides a way for a team to understand and evaluate code that they might not otherwise know, should a bug in that piece of software appear in the field, and the original author may not be available to triage and fix it.

Apart from that, code reviews help developers identify integration issues well before the code is checked in and this alleviates the burden on QA/QE and, eventually, results in a better product in the end (again).  The entire goal is to create a more robust, well-architected and well-designed product that has few bugs in the field and happier customers.

Leading to more money so you can afford that ridiculous mortgage and send your kids to a decent school...  (I see this among all my married w/ kids friends).

Coming next...... Types of code reviews and pointers on how to conduct them effectively

My dream coming true... fingers crossed

A dream and a hope that I had 4 years ago is finally coming to fruition - all due to the gumption and hard work of a handful of volunteers who all decided at the end of July that they would really like to make my dream come true.


And that they really didn't have any truly technical conferences for women to go to.  
We had gathered for a volunteer appreciation lunch and 5 of us decided that this would be worth it for all of us - Anne, Sushma, Deepa, Blythe and myself.  

Blythe signed up to be the conference chair and I signed up to be her mentor/guide/instructor and whatever else was needed.  And we formed the conference committee, recruited Val and Whitney for the website and graphics and we were on our way. 

That was 2 months ago. 

And so, on the heels of the Grace Hopper Conference this year, we, at CodeChix, are one week away from our first technical conference - Coder[xx] - Unleash the engineer within you.  To be held at the illustrious Computer History Museum in Mt. View on October 25.  

Coder[xx] is pronounced "Coders" and the double-x stands for the double-x chromosome.

And we are almost sold out.  Thanks to PayPal and Deepa Dhurka for getting us some funding but we are pretty much running this conference on ticket sales.

I had instructed Whitney to create a logo with the Andromeda Galaxy (I like stars/space) and with the slogan "Unleash the Engineer within you" and she, once again, created an amazing logo and banner.  And it sports our well known VT100-inspired color-scheme of black and green which I had originated in 2010.

And none other than the pioneering Mary Lou Jepsen is our keynote speaker !  I am so happy and grateful to her for accepting my request.

If you are a woman engineer who is serious about her career, you should come to this conference.  And if you have a daughter, bring her !  I feel that both daughters and sons need to see their mothers in their element - being fantastic engineers and being serious about their professions.  That is why, I created the "Mother & Daughter" ticket - for all the awesome mothers who need to show their daughters (we'll open it up to sons next year) how great they are.

This is the banner Whitney created per my specifications: