Category: Book Reviews

Sep 12 2025

Book review: Storytelling with data – Before and After by Knaflic, Cisneros and Velez

I recently reviewed Cole Nussbaumer Knaflic’s Storytelling with data, as a result the Storytelling team sent me a (pre-publication) copy of their latest book, Storytelling with Data – Before and After by Cole Nussbaumer Knaflic, Mike Cisneros and Alex Velez. It is scheduled for publication on 15th September 2025.

I must admit my first thought on receiving this book was “Can one have too many Storytelling with data books?” On the basis of this one I can say it would appear not!

Sadly, Daphne the data visualisation dragon, from Knaflic’s book Daphne Draws Data, is missing. The presentation is rather more austere, that said all of Storytelling with data books are beautifully produced.

The book is comprised of 20 “before and after” chapters showing a visualisation before the Storytelling treatment and the after of the visualisation after the treatment. There is some material at the beginning and end of this set of chapters. The preamble is a quick sketch of the elements of the Storytelling with data method which is to think of a data visualisation / presentation as a story and craft it accordingly.

The chapter at the end of the book talks about personal development for the reader and how this fits with the workplace. This touches on the material in Storytelling with you which talks about data presentations as a performance.

Each of the “before and after” chapters focuses on one element of the Storytelling with data scheme, and is written by one of the three authors. I like that the individual authors are identified with each chapter. Each author has a style but they are all good and they get an equal share of the chapter pie.

I think this format is a great choice, I found in earlier Storytelling books that talking through an example made clear more abstract ideas – when I’m setting out on some new technology I always look for an example close to what I want.

The before and after format is well suited to the core “narrative arc” of Storytelling with data. There’s the “background” – the context whose flaws are revealed by a “rising action” of highlighting its many deficiencies reaching a “climax” followed by a “falling action” as those deficiencies are resolved; ending with the “resolution” of the “after” presentation.

The examples used are from real engagements with customers but anonymised, covering a range of topics but generally around marketing. Many of the “before” visualisations struck a chord with me, they are so familiar from my working life. The key issue with them is that they try to fit too much in to too small a space. Their formats cover presentations, dashboards, periodic reports and in one case an email report.

The Storytelling method is fairly light on prescriptions for charts, it tends to stick to simpler chart types – often bar charts or dot plots (which are tricky to achieve in Excel, but there are links to guidance on this). The main advice is decluttering, taking out all the chart elements that don’t support your message.

One trick I learnt from earlier books is to title slides with the take home message rather than a broad description: “Results” is replaced with “Sales are up in the North West region”. This type of change is quick and easy to do, in fact one chapter talks specifically about the sorts of changes you can implement in 5 minutes, 15 minutes and 1 hour – I found this really handy.

I liked the chapter Draw Attention to What Matters this invites the reader to record where their eyes are drawn and in what order – in the initial example the author highlights a truncated logo and company logo – definitely not the intention. You may have seen this visualisation on how your attention can be utterly predictable.

In the final before and after chapter, Weaving it all Together, Knaflic talks about changing your mindset from informing to influencing. Ultimately you know the data best, and it is for you to recommend a course of action based on the data. Part of this is about understanding, and speaking to the interests of your audience.

As I read I realised a key deficit for me was seeing how to execute the transformations that Storytelling suggests in my favoured data visualisation software (Excel, Tableau and PowerPoint). Fortunately the team have that covered, there is the Storytelling with data: Let’s Practice book by Knaflic which I haven’t read and the Storytelling with data website has additional material on technical specifics as well as a community with data visualisation challenges.

In summary, I don’t think you can have too many Storytelling with data books – this one is great for those who like learning by example.

Dec 12 2024

Book review: The Rust Programming Language by Steve Klabnik and Carol Nichols

My next review is a small departure, it is for The Rust Programming Language by Steve Klabnik and Carol Nichols but rather than buy the physical book I read this interactive version, which has quizzes and embedded, runnable code.

The Rust programming language is the target for my next Rosetta Stone blog post which identifies all the tooling for a language. For Rust these tools (the compiler, formatter, linter, package management and automated documentation) are pretty much all “built-in” so my job will be easy. The challenge in this case has been learning the language since I try to write a little code for the Rosetta Stone posts to demonstrate what I’ve learned.

Rust is a relatively new language, very highly regarded amongst developers and one of only two approved for developing Linux. Its focus is on “safety” and speed. It has been used to make new, highly performant tools for the Python ecosystem, like ruff and uv, which is how I came to know of it.

For a Python programmer Rust does not look alien in the way that Haskell and Lisp do; admittedly it uses curly braces for scoping, is strongly-typed and supports pointers and references which are not features of Python but are common in other languages.

To me it feels like C but with some object-oriented features; the authors talk explicitly about it having features of functional languages including use of the Option value which contains something or nothing, the compiler enforces the handling of nothing. I think I might start using this more explicitly in Python which allows type-hinting to indicate an Option-like value. The other explicitly referenced functional feature is the use of closures, in Python closures are functions defined within functions or anonymous / lambda functions whilst in Rust they seem to be closer to functions passed as arguments to other functions.

Rust makes what seems an odd distinction between functions and macros in its standard library. Macros are identified with an exclamation mark, for example println! As I understand this is because a macro is implemented using code generation at runtime which allows the developer to supply, for example, a variable number of arguments to println! which would not be possible for a function println. Python doesn’t make this distinction and is very permissive in the arguments that a function can take, allowing both position and keyword arguments of variable number.

I was struck by the way that different languages use the same word for different things. For example in Rust a struct is both a data container but can also carry methods in the way that “classes” in other languages do. In Python an enum is a closed list of values but in Rust those values can have user-defined associated values so that an enum for IP address protocols can contain V4 and V6 (as it would in Python) but in addition it can hold an actual IP address associated with each entry in the enumeration.

My understanding is that Rust is considered an object-oriented language by some but not all. In practical terms the only object-oriented feature missing is inheritance although this can be approximated by the use of generics and traits.

Since I have scarcely used pointers and references in 40 years of programming I found these concepts a bit challenging but I have made progress in my understanding through reading this book. Excited by this new found understanding I was then confused by Rust’s ownership model! Ownership and borrowing are the big, unique conceptual features of Rust. The aim of ownership is to rigorously ensure that code is safe – no writing past the end of arrays, or dereferencing null points. It also means that the performance hit of a garbage collector is not required, this task is pretty much entirely handled at compile time by the borrow checker. The strong ownership model makes concurrent programming easier too.

In trying to understand ownership and borrowing I found some useful tools, the best entry point was the BORIS tool by Christian Schott which lists other visualization tools including the Aquascope tool used in this book. I found the first such tool in RustViz which is used in teaching, it needs the user to put annotations into the code rather than working out the annotations itself. I also read this article by Chris Morgan.

As language books go, this one is pretty readable, and I found the built-in quizzes handy, if only to illustrate my ignorance particularly of the ownership and borrowing model. I think for my next technical book I might read Category Theory for Programmers by Bartosz Milewski. I have felt when applying type-hints to Python, and learning Rust and Haskell that I was missing out by not understanding at least the basics of category theory.

I enjoyed this book and the format worked pretty well for me, although I need to find a way of reading online content like this in more comfort. I’m keen to give Rust a go now!

Aug 31 2024

Book review: Beautiful Code edited by Andy Oram & Greg Wilson

This review is of Beautiful Code edited by Andy Oram and Greg Wilson, a collection of 33 essays by 41 authors about computer code that the authors consider beautiful. A number of the authors are very well known, including Brian Kernighan, Charles Petzold, Douglas Crockford and Yukihiro Matsumoto.

The chapters vary considerably in length but average a little under 20 pages which works well for me – I find 20 pages is a reasonable chunk to read in one go. Although the chapters are presented without any organization, they are actually grouped into themes.

A few chapters are on algorithms, which is what I think of when people talk about beautiful code. A few chapters are on applications, and their architecture, a couple are on assistive technologies, a couple are on libraries/frameworks. A few are on operating system code: device driver architecture and handling threads. It is fair to say that beauty is in the eye of the beholder, and generally I felt authors wrote about their favourite piece of work rather than something that might be broadly considered beautiful code.

Several chapters I was more interested in the subject area than the actual code. There are a couple of chapters on bioinformatics (I was a lecturer in Biological Physics for a couple of years), a couple on Python (my primary programming language for the last 10 years or so) . The Python chapters are on the implementation of the dictionary in the core language and multidimensional iterators in Numpy (a widely used numerical library). The NASA chapter was a bit of a let-down since it involved strictly ground based code. However, I was excited to learn about the challenges of two Martian time zones as well as earth based time zones!

Pretty much all of the chapters contain moderate amounts of code. The implementing language varies, there are a number written using examples in Lisp. Ruby and Perl have a couple of outings, as does Haskell, also present are Java, C#, Python and C. Reading through the author biographies it seems some of them were involved in the creation or ongoing development of some of these languages.

I gave up on one chapter in part because it was in Lisp (not a language I’ve ever used) with no support except a suggestion to go read the first few chapters of the author’s book on Scheme (a dialect of Lisp) but also because it was about macro expansion which I’ve always considered a nasty kludge. Brian Hayes’ chapter also used Lisp but provides a little schematic diagram showing the structure of a Lisp function which was really helpful. Lisp programmers really like their brackets!

It was interesting to learn about Lisp’s advice functionality which is like Python decorators. Haskell is neat in its very clean separation between pure functions and functions with side effects. I can’t help thinking that both languages are best suited to highly mathematical developers working alone, their notation is exceedingly concise and impenetrable to outsiders. However, ideas from these more esoteric languages are usefully incorporated to more mainstream ones and programming styles.

Binary search and sorting are a feature of several of the early chapters. One author points out it took 12 years after its invention for a correct implementation of binary search to be written, and only 10% of developers get it right first time when implementing it themselves. The core error is an issue with numeric overflow which highlights that the difficulty of coding comes not just from algorithmic design but also lower level implementation details. The later chapter on the numerical analysis libraries from CERN (BLAS, LINPACK, LAPACK) highlight this again, optimum algorithms changed as the underlying machine CPU, memory and network architectures changed. The book finishes with a chapter on algorithms for checking the collinearity of three points on a plane, I liked this one. The twist at the end is that the best algorithm is to measure the area of the triangle the three points form, if it is zero then the points are colinear. This algorithm has the benefit if numerical stability, again a imposition of underlying numerical representation.

I liked the chapter on a logging framework, it made frequent references to design patterns and seemed like a nice example of beauty in higher level design.

In my view Charles Petzold’s chapter describes eldritch code, rather than beautiful! He shows how to generate C# intermediate language (IL) at runtime in order to speed up image processing operations. This involves line by line generation of raw IL using C#’s reflection functions. I’m not saying it is not very cunning or interesting but it isn’t pretty. It is also a personal interest of mine since I spent a number of years working on image analysis.

Some of the applications discussed have stood the test of time, ERP5 is still around as is Emacspeak (accessibility software for the blind). I can find no trace of Cryptonite (an email client) or Elocutor (accessibility software originally designed for Professor Stephen Hawking). Components of the Subversion and Perforce source control applications are included. Obsolesce seems to be a combination of the language used, the change in the web and competition. Beautiful Code was written in 2007, nearly 20 years ago and the web was a very different place then.

A couple of chapters talked about how code appeared on the page – I particularly liked the idea of “bookish” code, code laid out in the manner of a book or magazine to aid readability – interestingly this chapter was in favour of shorter variable names for readability rather than longer ones for description. A recurring theme is that the code is never beautiful in the first instance, it normally reaches beauty by a process of iteration and refinement.

The book was first published in 2007, and its age shows in some places. It finishes with biographies of the authors which could have more usefully been put with their respective chapters. I was sad to see that only one author appears to be a woman, I suspect this would be the case if the book was written now.

I enjoyed this book, most of the chapters struck some sort of cord with me.

Aug 17 2024

Book review: Daphne Draws Data by Cole Nussbaumer Knaflic

I recently reviewed Cole Nussbaumer Knaflic’s Storytelling with data, as a result the storytelling team sent me a (pre-publication) copy of their latest book, Daphne Draws Data scheduled for publication 29th October 2024 (UK) and 4th September 2024 (US). This is something of a change for me in the sense that the book is targeted at teaching data visualisation to the 6-9 year old age group. I am 54 – however, I have a 12 year old son and an interest in education. I have never reviewed a book intended for children before.

The first thing to say about this book is that it is beautifully illustrated by John Skewes. As I write this review Daphne (a dragon) is looking out at me from the cover of the book which has put a smile on my face.

The book follows Daphne as she visits various locations, and helps the creatures she finds there by collecting data and drawing graphs (having first reassured them that she was not going to incinerate them!). This is very much like my own career. I particularly liked the visit to the ocean where she draws a graph showing that shrimp and crabs move at the same speed if you allow for the size of the creature. This is quite sophisticated scaling analysis that I’ve taught to undergraduate physics students.

The book finishes with a glossary of chart types which is reminiscent of the material in Knaflic’s books for adults. I was slightly disturbed to see the caption “Eat a rainbow” close to an illustration of some coloured crayons but it is an exhortation for children to record the colour of the food they eat during a day and make a bar chart, rather than eating the crayons!

A children’s book fits very well with the central theme of Knaflic’s work on data visualisation which is the importance of storytelling. To be honest working out who is eating the monkey’s bananas is more engaging than the usual stories we tell in our business presentations.

I guess a key feature of books for children in this age group is that they are read with an adult, I imagine a lot of adults would learn from it too.

Alongside the book there is a website daphnedrawsdata.com which includes resources for educators, amongst much else. This shows how the book fits in with the Common Core requirements in the US school system, I’m sure this will align pretty well with the UK standards.

I’d have definitely bought this book during the COVID lockdowns as material for home-schooling, not only does it cover some data visualisation techniques but it also encourages the data collection that has been central to my life as a scientist. I’d probably also borrow the illustrations for any presentations (to adults) I might give on data visualisation.

Feb 08 2024

Book review: A Philosophy of Software Design by John Ousterhout

Next for review is A Philosophy of Software Design by John Ousterhout. This a book about a big idea for software design. The big idea is that good software design is about managing complexity. In Ousterhout’s view complexity leads to a set of bad things: (1) change amplification – small changes in code lead to big effects, (2) cognitive load – complex software is difficult to understand, and (3) unknown unknowns – complex software can spring the unexpected on us.

Ousterhout covers this big idea in 20 short chapters with frequent reference to a projects that he has run with students repeatedly (including a GUI text editor and a HTTP server) – providing a testbed for reviewing many design choices. He also uses the RAMCloud project as an example, as well as features of Java and the UNIX operating system. This makes a refreshing change from artificial examples.

To decrease complexity requires developers to think strategically rather than tactically which goes against the flow of some development methodologies. Ousterhout suggests spending 10-20% of time on strategic thinking – this will pay off in the long term. He cites Facebook as a company who worked tactically and Google and VMWare as companies who worked more strategically.

At the core of reducing complexity is the idea of “deep modules”, that’s to say systems that have a relatively small interface (the width) which hides information about a potentially complex process (the depth). The Java garbage collector is the limiting case for this – having no user accessible interface. The aim of the deep modules is to hide implementation details (information) from users whilst presenting an interface that only takes what is required. This means deciding what matters to the user – and the best answer is as little as possible.

This goes somewhat against the ideas of the Agile development movement, as expressed in Clean Code by Robert C. Martin (which I read 10 years ago) – who was a big fan of very short functions. I noticed in my review Clean Code that I have some sympathy with Ousterhout’s view – small functions introduce a complexity overhead in function definitions.

Also on the theme of Agile development, Martin (in Clean Code) sees comments as a failing whilst Ousterhout is a fan of comments, covering them in four chapters. I recently worked on a project where the coding style was to rigorously exclude comments which I found unhelpful, that said I look at my code now and see orphaned comments – no longer accurate or relevant. The first of Ousterhout’s chapters on comments talks about four excuses to not provide comments, and his response to them:

  1. Good code is self-documenting – some things cannot be said in code (like motivations and quirks)
  2. I don’t have time to document – 10% of time on comments will pay off in future
  3. Comments get out of date and are misleading – see later chapter
  4. The comments I have seen are useless – do better!

The later chapters focus on the considered use of comments – thinking about where and what to comment rather than sprinkling comments around at a whim. The use of auto-documentation systems (like Sphinx for Python) is a large part of realising this since they force you to follow standard formats for comments – typically after the first line of a function definition. Comments on implementation details should be found through the body of a function (and definitely not in source control commit messages). He also introduces the idea of a central file for recording design decisions that don’t fit naturally into the code. I include the chapter on “Choosing names” under “comments” – Ousterhout observes that if you are struggling to find a good name for something there is a good chance that what you are trying to name is complex and needs simplification.

Certain types of code, Ousterhout cites event-driven programming, are not amenable to producing easy to understand code. He also dedicates a chapter to handling errors – arguing that errors should be defined out of existence (for example deleting a file that doesn’t exist shouldn’t cause an error, because the definition of such a function should be “make sure a file does not exist” rather than “delete a file”). Any remaining exceptions should be handled in one place, as far as possible.

There is a chapter on modern software development ideas and where they fit, or don’t, with the central theme. Object-orientation he sees as good in general, with information hidden inside classes but warns against over use of inheritance which leads to complexity (just where is this method defined?). He also comments that although design patterns are generally good their over-application is bad. He is in favour of unit tests but not test-driven development. This seems to be related to his central issue around Agile development – it encourages tactical coding in an effort to produce features rapidly (per sprint). He believes Agile can work if the “features” developed in sprints are replaced with “abstractions”. He doesn’t like Java’s getters and setters, nor its complex serialisation system which requires you to setup up buffering separately from opening a file as a stream – I remember finding this puzzling.

I enjoyed this book – it provides some support for continuing to do things I currently do although they are a little against the flow of Agile development and food for thought in improving further.