Goodliffe, Becoming a Better Programmer (O’Reilly, 2014): A non-professional’s take

Goodliffe’s Becoming a Better Programmer is marketed to a wide range of readers: to veterans, newcomers, and also to those who do some programming on the side as a hobby (Hi!). This is not entirely accurate– the book clearly has professional developers in mind most of the time– but I found the book to be an interesting discussion of aspects of the art and craft of programming all the same.

The first two parts of the book discuss a number of features of writing and working with code, both the theoretical/philosophical side and lower-level issues like producing and maintaining consistently formatted code. These sections are clearly oriented primarily towards professional developers, who are probably working in a production environment, have an existing codebase to work with, and may well be under pressure to skimp on design or testing in order to ship code more quickly. Even so, in talking about all of the problems that particular code or a particular codebase can have, these parts also talk at length about the principles and design behind good, sane code, and I found these sections useful and interesting. He discusses cohesion and coupling, omitting needless code (the YAGNI principle), and producing simple and sufficient code– along with practical advice about stuff like testing and version control.

The last three parts of the book are concerned with the softer side of being a developer, both personally and interpersonally– working well with your team, responding to superiors, and even personal things like ethical considerations and the importance of good posture. These sections are lighter weight (and often briefer), and sometimes repetitively summarize earlier points in the book. But they’re an easy read, and can be humorous in a way that the sometimes strained jokes of other sections aren’t. (For example, Goodliffe talks about your relationship with your primary language as a marriage, but then notes that, unlike most marriages, it can be quite helpful to play around on your “spouse.”)

It’s worth pointing out that Goodliffe’s book seems much more oriented towards discussion than to armchair reading. Each chapter takes up a subject, discusses different approaches to that subject (sometimes briefly), and then gives a set of questions. In most cases, Goodliffe is undogmatic– he lays out his position in the text, but the questions leave open the possibility that other experienced developers might have a different take. This format seems like it would work well for reading with a mentor (as the book suggests) or even a book club.

Goodliffe’s language-agnostic approach makes the book broadly accessible but also somewhat abstract. I think the book would have been stronger if he were clearer about applying principles to particular languages. Goodliffe’s book will not replace the resources that give advice and best practices for the idiomatic use of whatever language you’re working in, therefore, but it’s a quick read, and may get you thinking about the way you code, even if it’s only something you do in your spare time.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s