On a software development team, we often talk about writing code, but less about the importance of getting effective and practical code feedback. Code that ignores established patterns or is buggy needs quality feedback to improve.
Keep the changes small.
Large pull requests (PRs) are sometimes unavoidable, but most of the time, they result from not breaking down work effectively. When PRs are large, reviewers may feel overwhelmed and have to pick and choose which parts of the PR receive their attention.
Team members might resort to rubber-stamping your PRs. This can lead to lower-quality code and a higher chance of bugs being overlooked.
Keep your work in scope.
Keep your work within the defined scope. If your story is about changing the network interceptor, avoid making unrelated changes, like modifying a button, in the same PR. Instead, create a separate PR for those updates. This allows reviewers to focus on the primary objective of the PR. Although you can make exceptions, especially when under time pressure, out-of-scope changes increase context switching for reviewers.
Provide good feedback.
Regularly review others’ PRs to stay in sync with the team’s coding practices. Consistent reviewing also helps maintain awareness of patterns and fosters collaboration. The more you review, the better you’ll understand and reinforce code consistency.
Set the tone.
Ask for tone indicators on PRs to make it clear when changes are blocking and when they aren’t. This practice prevents reviewers from focusing too much on minor preferences, especially when under time constraints. Avoid blocking PRs over subjective naming choices unless they violate an agreed-upon standard.
Stop nitpicking.
Yes, you’re being too picky! Things won’t always be perfect, and there are often multiple valid ways to implement a solution. Before offering feedback, ask yourself if it’s truly a better approach or just your preference. When possible, clearly indicate if a comment is a preference or a must-do. Use the PR-blocking feature wisely and encourage open discussion rather than enforce specific stylistic choices unnecessarily.
Write tests.
Writing tests helps reviewers assess how robust your code is. Reviewers can suggest additional edge cases and run tests themselves to verify that the code works as expected.
Teach and learn.
At Atomic, we have a principle of teaching and learning from each other. How can you promote this on your team? Consider setting up dev syncs where you share helpful Android Studio features or coding tips that other developers may not know about.
Practical Code Feedback
Effective and practical code feedback is more than just pointing out errors. It’s about fostering a collaborative, productive environment where everyone grows together. By keeping PRs manageable, staying within scope, and providing constructive feedback, you help maintain a high standard of code quality across the team. Remember: focus on what really matters, use tone indicators to communicate clearly, and keep an open mind when reviewing. The more you engage with the team, the better you’ll understand the codebase and contribute meaningfully. So, let’s keep learning, teaching, and improving — together.