Skip to main content

Respect and Code Reviews

Code Reviews in a development team only function best, or possible at all, when everyone approaches them with respect. That’s something I’ve usually taken for granted because I’ve had the opportunity to work with amazing developers who shine not just in their technical skills but in their interpersonal skills on a team. That isn’t always the case, so I’m going to put into words something that often exists just in assumptions.

You have to respect your code. This is first only because the nature and intent of code reviews are to safeguard the quality of your code, so even having code reviews demonstrates a baseline of respect for that code. But, maybe not everyone on the team has the same level of respect or entered a team with existing review traditions that they aren’t acquainted with.

There can be culture shock when you enter a team that’s really heavy on code reviews, but also if you enter a team or interact with a colleague who doesn’t share that level of respect for the process or the code. This mismatches can lead to conflict, arguments, resentment. They can lead to dwindling code quality and eat at the respect and will the whole team has for adhering to the code review.

Hold fast if a new member joins your team who doesn’t buy into the code review sanctity. They will often take code review feedback personally, and their apparent disregard for your suggestions is easy to take personally, as well. That’s a recipe for bad blood and arguments, so try to defuse it quickly.

This brings us to the next respect you need to have.

You have to respect your teammates. You aren’t a collection of programmers who just happen to be working on your tasks in the same codebase. You don’t function independently within the team but as a unit. Code reviews are one thing we do to guide and enforce that idea.

The respect for your teammates goes both ways during a code review. There is respect from the reviewer to the reviewee, as well as the reviewee to the reviewer.

As a reviewer, your attitude and approach can make or break your colleagues' respect for the process, the team, and you. There are some easy tips in the feedback you give and especially in how you give it, which can make them easier for both sides.
  • Try to avoid blaming “you” language. Don’t say “You didn’t do this right” when you could say “This would be less likely to break if…”
  • Use “we” language to convey the team ownership of the code. If some code convention wasn’t followed, don’t say “I prefer that you…” or “You incorrectly…”, rather say “We always follow array items with a comma, even the last one.” etc.
  • When using “I” language, use soft phrasing. Don’t say “I need” or “I know”, but “I usually” or “I’ve always found”.
  • Just be respectful and review the code for the team, not against the reviewee.
You have to respect your reviewer. I’ve given most of this advice from the perspective of reviewing code, but this rule is all about having your code reviewed.

The first rule of having your code reviewed is “Don’t take the code review personally”. Your code is not a reflection of you and it is never perfect. Your approaches can be great, but everyone can have valuable feedback. Accept feedback with some empathy and humility.

The second rule of having your code reviewed is “The team reviews your code because the team owns your code.” You do not own your code. Even when you’ve just written it when no one else has touched it yet, even if you put hours of effort and sweat into it. You do not own your code, this bears repeating. So, when your code gets reviewed remember that what eventually ends up in the project has to meet the team’s standards and idiosyncrasies. Often, it is essential that you bend your own preferences. You have to allow the code to work for the whole team, even changing your vision. Our code styles and practice should be in context to the team and project we work in, so don’t be completely tied to one approach, even if it’s your favorite approach.

You have to respect yourself. I’m not to write this without including the respect you need for yourself because the rest of the article was dominated by everyone else. Of course, this can mean a lot of things.

Respect yourself to speak up or push back when feedback you get really is wrong, in your opinion. Make your case strongly, but still keep all the advice above in mind when finally coming to a conclusion.

Respect yourself to be a little dignified responding to code review feedback. Don’t take it personally and look petty. Don’t ignore any bits of the feedback without making a case for why, looking dismissive. Don’t get angry about changing code you really looked and highlight your ego.

Respect yourself enough to look good in your teammates' eyes at the end of the process so everyone can be happy with what finally goes into the project and shared by the whole team.

Comments

Popular posts from this blog

CARDIAC: The Cardboard Computer

I am just so excited about this. CARDIAC. The Cardboard Computer. How cool is that? This piece of history is amazing and better than that: it is extremely accessible. This fantastic design was built in 1969 by David Hagelbarger at Bell Labs to explain what computers were to those who would otherwise have no exposure to them. Miraculously, the CARDIAC (CARDboard Interactive Aid to Computation) was able to actually function as a slow and rudimentary computer.  One of the most fascinating aspects of this gem is that at the time of its publication the scope it was able to demonstrate was actually useful in explaining what a computer was. Could you imagine trying to explain computers today with anything close to the CARDIAC? It had 100 memory locations and only ten instructions. The memory held signed 3-digit numbers (-999 through 999) and instructions could be encoded such that the first digit was the instruction and the second two digits were the address of memory to operate on

Statement Functions

At a small suggestion in #python, I wrote up a simple module that allows the use of many python statements in places requiring statements. This post serves as the announcement and documentation. You can find the release here . The pattern is the statement's keyword appended with a single underscore, so the first, of course, is print_. The example writes 'some+text' to an IOString for a URL query string. This mostly follows what it seems the print function will be in py3k. print_("some", "text", outfile=query_iostring, sep="+", end="") An obvious second choice was to wrap if statements. They take a condition value, and expect a truth value or callback an an optional else value or callback. Values and callbacks are named if_true, cb_true, if_false, and cb_false. if_(raw_input("Continue?")=="Y", cb_true=play_game, cb_false=quit) Of course, often your else might be an error case, so raising an exception could be useful

How To Teach Software Development

How To Teach Software Development Introduction Developers Quality Control Motivation Execution Businesses Students Schools Education is broken. Education about software development is even more broken. It is a sad observation of the industry from my eyes. I come to see good developers from what should be great educations as survivors, more than anything. Do they get a headstart from their education or do they overcome it? This is the first part in a series on software education. I want to open a discussion here. Please comment if you have thoughts. Blog about it, yourself. Write about how you disagree with me. Write more if you don't. We have a troubled industry. We care enough to do something about it. We hark on the bad developers the way people used to point at freak shows, but we only hurt ourselves but not improving the situation. We have to deal with their bad code. We are the twenty percent and we can't talk to the eighty percent, by definition, so we need to impro