Books
The Book I Wrote
-
Outside-In React Development: A TDD Primer
Learn how to build React apps using outside-in test-driven development, including end-to-end tests with Cypress and unit tests with Jest and React Testing Library. Includes an extended exercise building two application features. See how outside-in TDD leads to a thorough test suite, better regression safety, and a faster development speed.

Outside-In React Development: A TDD Primer
Learn how to build React apps using outside-in test-driven development, including end-to-end tests with Cypress and unit tests with Jest and React Testing Library. Includes an extended exercise building two application features. See how outside-in TDD leads to a thorough test suite, better regression safety, and a faster development speed.
Other Books I Recommend
These are the top books on programming I’ve read. Each has majorly improved my quality of life as a programmer.
Links take you to InformIT, a distributor where you can buy physical books or DRM-free ebooks.
The links below are affiliate links: if you purchase through them I make a little money without any cost to you. If you’d rather not use these links, feel free to search for these books at your preferred bookseller. I recommend InformIT for DRM-free ebooks.
-
Extreme Programming Explained
How can we write software in a way that is ready to flex with change, instead of treating change as an unexpected problem?
-
Growing Object-Oriented Software, Guided by Tests
How can we write tests that ensure our system behaves as it should and that our code is easy to work with?
-
Object Thinking
Why are some developers drawn to statically-typed languages and upfront planning, and others drawn to dynamically-typed languages and agile methodologies?
-
Practical Object-Oriented Design: An Agile Primer Using Ruby
How can you write software that stays easy to change over time? (The principles apply to any programming language, although non-object-oriented languages will take a bit more work to get there.)
-
Refactoring
How can you make improvements to software without having to do large, sweeping, risky changes?
-
Smalltalk Best Practice Patterns
What small decisions can we make arranging our code to make it easier to maintain? (The principles and way of thinking apply to any programming language.)
-
xUnit Test Patterns
What can you do when your tests are having problems and you aren't sure how to fix them?

Extreme Programming Explained
How can we write software in a way that is ready to flex with change, instead of treating change as an unexpected problem?

Growing Object-Oriented Software, Guided by Tests
How can we write tests that ensure our system behaves as it should and that our code is easy to work with?

Object Thinking
Why are some developers drawn to statically-typed languages and upfront planning, and others drawn to dynamically-typed languages and agile methodologies?

Practical Object-Oriented Design: An Agile Primer Using Ruby
How can you write software that stays easy to change over time? (The principles apply to any programming language, although non-object-oriented languages will take a bit more work to get there.)

Refactoring
How can you make improvements to software without having to do large, sweeping, risky changes?

Smalltalk Best Practice Patterns
What small decisions can we make arranging our code to make it easier to maintain? (The principles and way of thinking apply to any programming language.)

xUnit Test Patterns
What can you do when your tests are having problems and you aren't sure how to fix them?