There’s so much I’d like to preface this post with. Never before have I had to confront myself as deeply as I have while reading Extreme Programming Explained by Kent Beck. It feels a bit silly, honestly. I’ve been programming for 4+ years now. I’ve made a solid impact at my job and proven myself as a dependable software developer. Me aside, it’s been 20 years since the book was first published, and many of the practices it promotes are now commonplace. So why does this book still challenge me so deeply?

Because it’s shined a light on my weaknesses and illuminated a path to mastery that feels further out than I had previously thought.

Before picking up this book, I felt I had a strong programming foundation and was progressing steadily toward becoming a proficient software engineer. I’ve advanced quickly in my company, thanks largely to my soft skills built up in my previous career, and I was reasonably confident in my technical abilities—or at least confident that through sheer grit I could get through any challenge. That perspective has since shifted.

Kent Beck’s analogy of knowing how to garden versus being a master gardener struck a chord with me. Can I look at an application’s architecture and intuitively understand the factors at play? Can I easily identify the trade-offs in design decisions? Do I truly know where my effort is best applied or when to shift focus? These lessons undoubtedly come with experience, but they also require deliberate practice and reflection. Without active effort to internalize and apply these lessons, they risk fading into the background of day-to-day work.

Extreme Programming Explained challenges you to bring your best self to the table with an almost blinding sincerity—like staring at the sun. Its glaring positivity assumes the best of everyone: that the team is eager to collaborate and improve collectively. While this might sound utopian, it still serves as a solid guidepost for moving a team toward better software. Beck’s small caveats, such as “this is not prescriptive” or “each team must adopt at its own pace,” feel like reminders that you get out what you put in. Nothing will change without effort and intentionality.

I didn’t expect this book to be a hard read. I thought I’d encounter opinions and practices I already understood or had adopted. Instead, I’ve found myself re-reading pages, often trailing off into deep self-reflection about my performance on current projects.

I’m excited to keep reading and will share more updates as I work my way through the book. Until next time.