Working in Teams
You Are Not Your Code
Agenda
- Performing code reviews
- Separating yourself from your code
Performing Code Reviews
A code review is a systematic examination (sometimes referred to as peer review) of computer source code. It is intended to find mistakes overlooked in the initial development phase, improving the overall quality of software.
Why Do Code Reviews?
- Great learning opportunity
- Lowers chances of bugs
- Team building
Good | Bad |
---|---|
"Can you review this function?" | "Can you review this application?" |
"Can you walk me through how this if statement works?" | "Why did you do spaces around the condition of your if statement?" |
"That nested ternary might be more readable as 2 if statements." | "I can't even read this code. What were you thinking?" |
"What would happen if we passed X into the function?" | "I can't believe you missed the edge case of passing X into the function." |
"I think it would help with readability to split these expectations into separate examples. Here’s a reference: http://betterspecs.org/#single." | "This is the wrong way to structure the test." |
What are the differences between the Good and the Bad?
Discuss with your neighbor.
Code Review Sayings
Guidelines [link]
- Ask questions. Don't make demands.
- Accept many programming decisions are opinions.
- Ask for clarifications.
- Avoid ownership words: "your", "mine", "not mine".
- Assume well meaning and avoid words such as "dumb" and "stupid".
- Be humble.
- Avoid sarcasm.
- ---
- Be grateful.
- Explain why you did things the way you did things.
Mostly Inappropriate Topics:
- Style (Should be automated if it matters)
- Architecture (Should be decided before looking at code)
Taking Criticism Constructively
- Supress your first reaction
- People give criticism to help
- Ask questions to understand the criticism
- Show appreciation for the feedback
- Request to follow-up on the criticism
Separating Yourself from Your Code
If you get defensive when you receive feedback about your code:
Get over yourself.
You're in this code review to get better at programming. Not to have everyone congratulate you. So, take feedback as opportunities for growth and make sure you follow-up on it and improve.
If you get anxious when you receive feedback about your code:
Remember the feedback is to help you.
You're in this code review to get better at programming. Not to defend your code like a dissertation. Take feedback as an opportunity for growth and be grateful.
Here is some of the first open source code I have written.
The code is still there being code.
Written by me, but is definitely not me.
This Can Get Philosophical Really Fast
Ideas live a life outside of their creators...
Great ideas can be used for horrible things.
Horrible ideas can be used for great things.
Same goes for your code. It is not you. It is code.
Agenda
- Performing code reviews
- Separating yourself from your code
Working in Teams: You Are Not Your Code
By Danny Fritz
Working in Teams: You Are Not Your Code
- 702