Edgser Dijkstra is a giant in the field of software engineering. Over his career he’s said a lot about the way developers go about their business, including how developers need bugs. I don’t necessarily agree, but there’s a lot to think about there.
People can have virtues. So can code. In general, for better code, you maximize virtues and minimize smells
As leader of a Software Quality team, part of my job is to measure and report on code coverage. The thing is, code coverage, by itself, isn’t enough to prove correctness and provide confidence. But it is something that helps you along the way.
You might thing Safety Nets and Guardrails are the same thing, but they’re not. They both make things safer, but how and when they work are very different.
Tests come in many different flavors, and which flavor you want depends on what you’re trying to validate with the test.
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.