Books that made me a better developer

Occasionally I see posts listing the books that “changed the author’s life”. This is my attempt to explain how these books made me a better developer. The ones that influenced me the most were the ones I read shortly after beginning my career, when I had no idea what good code looked like.

Working Effectively with Legacy Code

The company I started my career at had a lot of problems with their software. The core product that made the company money had been written in an obscure language, by a “happy amateur” (as described by another senior developer), but even the newly re-written applications in .NET weren’t very good. This was a small company located outside of any major urban centers, and so didn’t have a big market of experienced engineers to tap.

I realised I needed to learn how to read, debug and refactor all this “legacy” code. I write “legacy”, because that was a nebulous term, just a feeling that it wasn’t as robust or extensible as it should have been. To that end I bought Michael Feathers’ “Working Effectively with Legacy Code”.

Feathers defines legacy code as “code without (automated) tests”, and that accurately described what I was dealing with. My team was re-writing software and as soon as it was released it was legacy code. What a demoralising state of affairs!

He shows ways of changing classes and methods in small increments, such that the developer is confident that they aren’t breaking anything. At this point automated tests can be added that assert the existing behaviour and therefore facilitate further refactoring. This was like being thrown a life-preserver whilst drowning. This wasn’t the only benefit though. By describing what bad code was, it also implicitly shows what good code looked like. To someone just out of university that had memorised the definitions of interfaces, abstract classes and object-oriented programming, this was the teacher of how they should actually be used.

Dependency Injection in .NET

This book, by Mark Seemann, was complementary to “Working Effectively with Legacy Code”. Although the book specifically targets a single platform with examples, the ideas are universal. It shows how applications should be structured to enable automated testing and to facilitate extending functionality.

It was the norm to see code with static members, directly accessing database or other external resources. This really helped put a nail in the coffin of the “singleton pattern”, probably the only pattern I was seeing in use.

Test-Driven Development by Example

This book by Kent Beck really helped to show how the features of software can be chiselled out by following the test-refactor cycle. Before I read this I had trouble conceptualising how software modules should have a singular, cohesive purpose. After I read it I became a bit of an evangelist and consequently a huge pain in the arse to my colleagues.

Nowadays it’s rare that I use tests to flesh out my code, but at the time it helped instil discipline when unit tests by other developers were incredibly rare. It does make me feel occasionally guilty that I don’t follow this process, and don’t have 100% test coverage, but I’ve found after acquiring more experience that most code follows a similar pattern, and writing it is almost automatic.

JavaScript: The Good Parts

In reality it’s been just a few years ago, but in terms of development of tooling, libraries and best-practices, it feels like web development has moved forward by decades. Back in the bad old days it felt like the wild west — completely lawless. Supporting multiple browsers was a nightmare, old versions of Internet Explorer were harder to kill than zombies and nobody really knew how to develop a javascript application of any size.

This book and jQuery were the forerunners, attempts to tame the madness. I imagine that many developers of applications, as well as the developers of a lot of UI libraries read this book. As better tools have become available, such as TypeScript, ESLint, unit testing libraries and view-model frameworks, approaches have become standardised and there are many examples of the “right” way of doing things. Because of this, in my view, the influence of this book has waned over time. When it was released, it was pretty revolutionary though!