Don’t Burn your Free Azure Credits, or Max Out the Corporate Card
August 13, 2024
Word Redundancy Factors
August 14, 2024

The Importance of Code Reviews – Shared Responsibility

Posted by TrueNorth

Just wanted to share a story from university that taught me early on the importance of peer reviews and your responsibilities as a reviewer.

The situation was a group practical during which we were designing a toy 4-bit microcontroller. The whole thing was mainly built out of MOSFETs if my memory is correct (my electronics is definitely rusty ~15 years down the line!). These were plugged together into basic logic gates, logic gates into half-adders and latches and so on. Each member of the group had responsibility for part of the final microcontroller: memory, ALU, clock, registers, control unit etc.

The whole thing was to be simulated on some industrial software that let you draw the gates in a CAD type interface. It then determined the layout and consequent masks that would be required to actually burn the wafer in a fab plant. It was all exciting stuff with NDAs being signed to use the software (I think it was probably a couple of generations old by this point, probably a 600nm process or something). And, just like punch card computing of yesteryear, the simulation of the design to check whether it will actually work when burned took a nightly run, no REPL for this badboy.

We had two shots to get it running over a 4 day practical. As well as designing your own part, everyone in the group of about 8 was assigned someone else’s part to check. So, there I was reviewing one of my peer’s work, and by god was it boring. My eyes were going square (probably not helped by the extremely cheap Queen’s College Bar that I frequented too often) as basically I was staring at a long truth table cross-checking the wiring of a mass of gates.

You can probably see where this is going, I didn’t do my due diligence. After checking about 60% of the table and finding no mistakes I thought sod this, surely there won’t be a mistake in the rest of it and signed it off.

We all arrived the next morning eager to see the results of the overnight simulation in which the microcontroller was put through it paces with a simple program. Needless to say, it had bombed out with all sorts of whacky signals going on. Much head scratching and debugging work followed until the fault was found. Yep you guessed it, a pesky 1 where there should be a 0 in one single line of the 40% of the truth table of one component that yours truly was supposed to have reviewed!

At the time, I was annoyed at my peer. How could he have been so slack in his own work?!

However, looking back with the wisdom of maturity (although I don’t think my peers needed much looking back to arrive at this conclusion), I can see that most of the fault was with me.

The moral of this rather length story is: you share responsibility for a piece of work if you have reviewed it and signed it off. If you can’t review it properly and have some confidence that it will work, then speak up loud and clear. Too often I see programmers treat peer reviews as a box ticking exercise, rubber stamping stuff that goes out the door and straight back in again when straightforward mistakes are missed. We are all human and mistakes get made, make it a mission to find at least one on every review you do!

Oh, and in case you were wondering, it did work next time

Get our Latest Articles in your Inbox

Enjoyed this article? Sign up for our email newsletter and get real-world information on all things Microsoft, cloud and tech. Your information will be shared with MailChimp but no one else, and you can unsubscribe with one click at any time

Sign-Up to Our Newsletter: