Continued from here.

Part 3

There’s more to quality than just all the tests passing.

The most interesting questions in software development are about trade-offs
Does my software work? In the ideal world, you get immediate feedback.
How frequently do you need feedback in the real world?
Different kinds of feedback that we need:
1. Is the software doing something useful?
2. Is my codebase healthy?
3. Have I broken anything?
TDD can make you over-confident (example of ignoring QA altogether)
Exploratory testing still valuable even for self-testing code
Every test needs to fail at least once

Part 4

Incremental small changes in design can cascade into major design improvements.

Trade-offs: under-testing vs over-testing
- If you can’t change code confidently: under-tested
- If you spend more time changing tests than changing code: over-tested
- The intended audience of the software is part of the trade-off
Is there a right ratio of code to tests? No, it depends.
Delta coverage: is this test testing something unique?
It’s OK to delete tests, especially if their delta coverage is zero
Commenting out code to check if any tests fail (similar to mutation testing with cosmic-ray?)
Only test things that can break
Example: throw away implementation, keep tests, write new implementation under old tests
Tests are the means to an end: user satisfaction

People cannot leave good ideas the fuck alone.

You either die a hero, or live long enough to become a villain.

Development isn’t a science, we can’t repeat experiments
… but a scientific mindset often helps.
You have to over-use something to understand its proper use (learn the limit by exceeding it)
TDD useful across various levels of developer experience
Junior devs often make the mistake of not refactoring enough (just red and green)
Senior devs should continue repeating the basics for the benefit of new people constantly coming through
Approaching ideas from first principles helps avoid wandering off-track