Chapter 3 of 4
Writing Good Software
Practical principles for writing maintainable, testable, and robust code.
Key Insights
Good code is code that other engineers can understand, modify, and extend with confidence.
Testing is not about coverage numbers — it's about confidence in changes.
The best refactoring is the one you do incrementally alongside feature work.
Notes
Code Quality Tradeoffs
There's no absolute 'good' or 'bad' code. Quality depends on context: a prototype needs different standards than a payments system. The key is being intentional about the tradeoffs. Understand when to invest in quality and when speed matters more.
The Boy Scout Rule
Leave the codebase better than you found it. Every PR is an opportunity to make a small improvement: rename a confusing variable, extract a helper function, add a missing test. These incremental improvements prevent code rot.
Testing Strategy
Write tests that give you confidence to refactor. Unit tests for complex logic, integration tests for critical paths, and end-to-end tests for key user journeys. The testing pyramid still holds: many unit tests, fewer integration tests, even fewer E2E tests.
Over-Engineering
The most common mistake senior engineers make is over-engineering. Building for hypothetical future requirements adds complexity today with no guaranteed payoff. YAGNI (You Aren't Gonna Need It) is almost always correct. Build for today's known requirements.
Quotes
“The best code is the code you don't have to write. The second best is code that's easy to delete.”
“Complexity is the enemy of reliability.”