Code reviews are part of almost all development workflows. How you write them, read them, and respond to them says a lot about a team’s culture. It’s also a way to adjust a team’s culture. How you use them is up to you.
Don’t just review it, review it BEFORE you show it to anyone. It’s good for you, it’s good for them, and it’s good for your code.
Providing customer value is what we’re all here for. Unfortunately, it’s not the only thing we end up doing because of demands on our time.
Clickbait titles aside, how you use your signals is important. Not just for measuring code coverage.
When you say you want quality software, what are you really asking for, and how can you get it?
Just what is readability anyway?
That’s pretty clever, so fix it.
Naming is important. Even if it’s applesauce
Some kinds of tests you just don’t want to write
There is a difference between testing before and after coding
Tests are like cleaning the lint filter on your dryer
Is it someone’s fault, the system’s fault, or a balance of both?
The purpose of testing is to increase confidence for stakeholders through evidence.