A story of one code review

As told by a developer: 

A. and D. told me that the changes that were done to method “E” on class “C” are not needed, and also those two test cases for these changes were not needed. So A. and I removed those. I promoted these changes to my stream.

I don’t really understand why. 

Also A. said that the test “T” should make sure we are asserting that those values are really still there. I thought it did do that, but I guess not.

Also D. suggested an improvement to the code that I don’t fully understand: In class “U” method “D” we can pass the “c” into the “T” method on line 35 and then we don’t need to pass it in on line 39. I didn’t catch exactly what he was saying to do.
I may be missing some other things too.

---

I hope the code was improved as a result of the changes made based on this code review.  But even so, this is not the best way to run code reviews.

Code review is there to get all the team members on the same page in regards to writing good code, catch hard-to-detect issues, and learn from each other.  The discussion that happens in code review is an invaluable tool in building a strong technical community, and ensuring the technical quality immediately and over the medium- and longer-term. It is important that all participants gain an understanding of what changes would make better code and why, in addition to simply following typing instructions.

Here's a slide deck "Effective Code Review" for a discussion about code review practices , that focus on learning, creating a community with a common vision, and building social capital.

Are we having fun yet?

Legoland theme-park has very few Lego creatures. A staff member explained:

- It is a lot of work building them out of small bricks. 

That just sounds backwards. Building with Legos is fun, not work. How can that be?

For the folks working at the Legoland building from Legos is hard work. The resort operates by strict, unbending rules. Cheerful staff, while smiling and genuinely trying to be helpful, is going by a well-memorized script. Thinking on the job is discouraged, and absolutely no initiative or having fun is permitted. These guys look and act like well-behaved robots, which they are payed to be during the work hours. Robots do not have fun, no matter the activity. 

Most of us are not paid to build Legos, but a lot of our jobs can be no less fun and creative than putting little colorful bricks together. It is important to not let rules, scripts, and check-your-humanity-at-the-door culture ruin that fun.