foreword
I’ve been coding for money for over 32 years this year, and coding for free for nearly 40! I’ve taught coding at two colleges and worked side by side with developers who were far, far better coders than I, at companies all over the world, like Microsoft, Nike, and Intel, among others. Early in my career, I had my code so completely eviscerated in group code reviews that it had me sobbing in my car in the parking lot.
It wasn’t until I read Adrienne’s book, Looks Good to Me: Constructive Code Reviews, that I realized that no one ever formally teaches us how to review code, or how to accept the review. It’s somehow just assumed that we’ll put a bunch of passionate coders in a room, have them warmly accept “this code sucks” as feedback, and have each happily head back to their desk to make needed changes with an open heart.
You may think programming is about raw competence, you against the machine, putting lightning in a bottle in a caffeine-fueled 2 a.m. coding session. It is—when you’re a one-person shop coding for yourself. But engineers nearly always work as part of a team, and even more often, we work on very large systems that can’t be held in a single human’s mind. Programming is a team sport, and humans are a messy bunch to assemble into teams.