Posted on

Book Review – The Pragmatic Programmer

This book is a classic. It doesn’t cover any particular language or technology, instead it provides general advice to the aspiring software developer. This advice is organised as seventy separate aphorism. Each of these numbered tips gives a general recommendation to improve your work. There is a lot of good advice in this book, and I can’t really cover it all in a single post. So I’m just going to try and cover some of the main themes and the parts that I did not agree with.

Modularity is a theme that comes up again and again. The authors advocate for code that is cleanly divided into orthogonal modules with clear APIs. This is, of course, very good advice. Another mantra they return to repeatedly is “DRY – Don’t repeat yourself”. Again, this is broadly good advice, you should definitely avoid unnecessary duplication. But in reality you are going to have to repeat yourself. In fact repeating yourself is often the best option. Another major theme is to avoid programming by coincidence. Again this is broadly good advice. You should not just randomly permute things until they work. However, sometimes this is the only way to find out how things do in fact work.

The authors also advocate for fixing issues whenever you see them. Sure this is a good idea. But the reality of a large complex system is that it just isn’t really possible. In a large evolving legacy code base, you will see a lot of awful code. If you fixed every issue you came across you would never get any work done. Also this kind of tinkering can be pretty dangerous.

The authors strongly recommend making your code highly configurable. They advocate for a model of software where you can completely change the behaviour of your binary with a change to a config file. In my opinion this is an anti-pattern. It makes code execution unpredictable. It makes reading and reasoning about code hard. Having to carefully trace how config values percolate through the code base can be a nightmare. Also, it leads to a lot of dead code, if no one is sure what code is actually used, old code will just be left to rot.

I think that the biggest overall issue with this book is that it is old: it was published in 1999. So a lot of the advice is out of date. I don’t mean that it has since proven to be wrong, but that it is now so widely accepted that you won’t need to read the pragmatic programmer to find it, it will just be part of any normal software development job. For example there is an entire section about how you should use source control. They also recommend using nightly tagged builds as well as integrating testing into your build process. There is even advice on how to use email!

Another problem with this book is that there are very few concrete examples given. This does help to keep the book relatively light and readable. But it makes it hard to relate the general tips to real world programming.

On the whole, this is a good book. It can be quite vague and dated, but there is definitely useful advice in there. I should say that a new edition of this book was published while I was reading it. I assume that it has been updated appropriately, however I didn’t read it so I really can’t say.

Posted on

C# In Depth – Book Review

Jon Skeet is a bit of a legend. He has the highest reputation score on Stack overflow. He got there because of his consistently patient, helpful and correct answers. He is probably the most prominent C# developer there is. So, when I started a new job as a C# developer, I decided to read Skeet’s book, C# in Depth.

It’s a very good book. There is one big problem however, the structure. This book is divided into five parts, each dealing with a successive major numbered release of C#. This chronological structure is quite strange. The overriding assumption of the author is that the reader is familiar with C# 1. Given that C# 2 was released 13 years ago, this is a pretty strange angle. It’s hard to imagine there are many programmers today who are familiar with C# 1 but need a detailed walk through of the new additions to the language in C# version 2 to 5. The book ends up a sort of mix between a history of C# and an intermediate user’s guide.

One example of the problem with this structure is how delegates are covered. They are first introduced briefly in chapter 1. Improvements to the delegate syntax in C# 2 are then covered in detail in chapter 5. In neither of these chapters is there a clear explanation of what delegates actually are or why they are part of C#. Indeed when we reach chapter 10 Skeet covers lambda expressions, which, in reality, make delegates redundant for most use cases.

Another victim of the unorthodox structure is the coverage of class properties. Modern C# syntax allows us to define properties in a very quick intuitive manner. In this book, first we learn about properties as they originally appeared in C# 1. Then, in chapter 7, we see how C# 2 allowed a mix of public getters with private setters. Finally in chapter 8 we see how properties are actually implemented in modern C#.

There is of course a benefit to covering older versions of the language in detail. C# is a language designed for enterprise development. So, if you code in it, you are likely to be working with a large legacy code base. This means that understanding what the language looked like in it’s various iterations is useful. However, these topics would be a lot better served if they were covered all at once, rather than being split over multiple chapters.

Skeet spends a lot of time covering Linq, which is great. Linq is a really cool feature of C#, and he covers cool details, like how to use extension methods and iterators to integrate your own code into LINQ. He also covers the query expression Linq syntax. This is the syntax that lets your write a linq expression in the style of a SQL query. Frankly I think Linq expression syntax is a monstrosity and should never be used, but it is probably useful to cover it, and explain how it works (it’s really just syntactic sugar for the normal linq syntax). There is also a useful section on async code, that gets into a lot of really useful detail.

Overall, Skeet has an ability to make some quite obscure topics interesting and accessible. He always presents new ideas with realistic and useful code snippets. Most important of all, he writes in a fun conversational style, that makes reading his book a lot more fun than a typical intermediate language guide.