Skip to content
Hallway
0:00 / 0:00

#codereview#railsconf#derekprior

RailsConf 2015 - Implementing a Strong Code-Review Culture

Confreaks

42K subscribers • 89 videos on Hallway • Conference channel

YouTube
  • Recommended by 2 people: 1 on Lobsters and 1 in engineering communities.
  • A classic. People kept recommending it from 2015 to 2023.
  • Presented by Derek Prior, software engineer

Intermediate. Assumes working knowledge.

44K views11 years ago2 recommendations

Tools and practiceTestingCode review and teamworkDeveloper productivity

Derek Prior explains how to build a healthy code-review culture focused on socialization, learning, and teaching rather than just catching bugs.

By Derek Prior Code reviews are not about catching bugs. Modern code reviews are about socialization, learning, and teaching. How can you get the most out of a peer's code review and how can you review code without being seen as overly critical? Reviewing code and writing easily-reviewed features are skills that will make you a better developer and a better teammate. You will leave this talk with the tools to implement a successful code-review culture. You'll learn how to get more from the reviews you're already getting and how to have more impact with the reviews you leave. Help us caption & translate this video! amara.org/v/G6iP/

Why it's here

2 people recommend this

What people say. Recommended as an excellent guide on how to conduct constructive code reviews and build a healthy team culture around pull requests.

phkon Lobsters • Recommends

RailsConf 2015 - Implementing a Strong Code-Review Culture
6View on Lobsters

u/blacklabel85in r/ExperiencedDevs • Recommends

On “My new team creates PRs without any description. How do I convince them to change or should I even?”

Had a similar situation at my company recently. I disagree with others on this thread that the ticket will have all the necessary info as in my experience that is rarely the case. It is on the dev to say why they made the changes they made. Not because they have to explain/justify themselves, but because it opens up the conversation. Reading through the diff is much easier with some technical context, which you likely won't get from the Jira ticket. This is an excellent talk I referenced in the presentation I gave to my dept about improving our PR culture and opening up technical discussions: link to this video
1View on Reddit