The Science of Code Reviews

Talk was nice. Got a bit more confidence abour our current review workflow.

Goede talk.

De tekst "mob programming" heeft een slecht contrast met de achtergrond, vooral op foto's. Contrast van de tekst is sowieso iets om mee rekening te houden.

Voor de rest mis ik een klein beetje structuur, misschien een outline?

Rick helped met to get the reasons behind why we all should do code reviews more clear. His presentation was also really good to follow with nice and real word examples from himself. Than like always a little tip to Rick: Try to make some slides which are dedicated to help developers to get code reviews up and running in their company/environment. I missed this part though you gave me a good answer after the presentation.

Great talk about code reviews. Especially the part were you talked about ego less programming.

Inzichtsvol. Goed om te zien dat ik het al vrij aardig goed deed. Verder had ik nog wat tips en tricks willen zien om bijvoorbeeld kleinere pullrequests te enforcen, of newbie teamleden mee te krijgen.

Prima presentatie die veel informatie geeft over de voor en nadelen van CodeReviews. De presentatie kan wel iets meer structuur, diepgang en tempo gebruiken.

Interesting and fun talk, good speaker.

I liked the egoless programming part

Nice talk with lots of insights. Done with knowledge of the subject and a proper touch of humor.

First of all, great talk! Also, an important talk.

What I realized yesterday while listening to you that this is also very much a talk about diversity, inclusivity and intercultural communication. Instead of problematizing those topics, you are showing what an inclusive, diversity leveraging approach towards a development practice (in this case peer review) looks like. Fine to keep it implicit like it is. Might be fun to experiment with more explicitly calling out these underlying principles.

When you talked about the Why of code review, you gave seven reasons. That's hard to remember. I'd rather have three reasons and if that really can't cover it, an extra slide with three more. Doing things in threes is just a common best practice and makes things easier to process in general. Three reasons you could consider to replace your seven: Quality Assurance, Guidelines and Learning. Then you can go into more detail with each reason.

In general I think your explanation of what core values are wasn't very clear. I'd say values have more to do with approach and (technical) mindset than with implementation details. Things you can value are for instance:
- That things are named intuitively and descriptively
- Clear separation of concerns
- Simplest possible solutions
- etc.

Finally, you've inspired me to start trying (technical) retrospectives at Yoast. Thanks for this talk!