Tag: Kent Beck

Kent Beck

A fairly quick read, and an interesting one. Structurally, I think this worked well as a book — there’s a flow to it, the sections lead from one to the next quite well — but it also does feel like, both in terms of size and of formatting of the larger section in the middle, like it could’ve been implemented as a deck of cards. Something like the Writer Emergency Pack, but for programmers.

I quite like the choice of the word ‘tidy’, though, which Beck spent some time explaining. In short, it’s meant to emphasize that it’s just a little change. This book isn’t about massive refactorings; it’s about moving a couple lines around so a function is easier to read, adding or removing a couple comments so that a new reader can easily understand what’s going on in this file, extracting a few lines into a helper function. Small changes, things that just take a moment and could, in theory at least, be a no-review-needed PR.¹ Well worth the hour or two it takes to read; check it out.²

1. A concept I’m not entirely sold on, still, but I may be biased by being the kind of person who enjoys reviewing PRs. ↩
2. This is a Bookshop affiliate link – if you buy it from here, I get a little bit of commission. It won’t hurt my feelings if you buy it elsewhere; honestly, I’d rather you check it out from your local library, or go to a local book store. I use Bookshop affiliate links instead of Amazon because they distribute a significant chunk of their profits to small, local book stores. ↩

Kent Beck

‘By example’ books really aren’t my cup of tea—going back and forth between a book and the actual thing in order to follow along is too much overhead for either activity to work well, and just reading along without doing it myself leaves the book feeling rather anemic a lot of the time. That said, this book wasn’t terrible; I enjoyed Beck’s writing style throughout the whole first part, he did a good job livening it up with some personality so it didn’t feel like reading a WikiHow article. But where my interest really kicked in was in the third part, where it switched to more of a traditional Programming Book style, just dispensing a bunch of condensed advice.

There’s some good little tidbits in the earlier part, though; I think my favorite one was:

[Automated] tests are the Programmer’s Stone, transforming fear into boredom.

A great way to think about it! Write tests so that instead of worrying something will break as you continue working on it, you just go ‘meh, now I’ve gotta wait for the tests to run.’¹

This was a quick read; if you’ve been doing some form of TDD, it probably won’t continua much that’s new, but it’s a nice way to get an overview. And if you aren’t doing TDD, go ahead and read it; as I said, it’s quick, and Beck makes a better case for TDD than I will in a single blog post. It’s available in the O’Reilly Library.

1. Although, ideally, it’s not much of a wait – this is the benefit of unit tests, in particular, that you make them small and very quick to run, and with that you’re able to run the relevant segment of them after every change. ↩