Skip to main content

Book Review: How We Got to Now by Steve Johnson

How We Got to Now is a book that I can't really put into any individual genre. It isn't a novel, isn't a collection of small stories, isn't purely educational, and isn't historical. It is a combination of all of these genres and that's what makes this book unique and enjoyable.

The book How We Got to Now describes, as suggested by its subtitle, "Six Innovations That Made the Modern World". In the introduction Steven Johnson describes evolution and the way one change can trigger a change throughout the course of all of evolution. He also explains various other casualty phenomena to create an overarching point of linkage throughout the whole book. The most notable of these examples is the butterfly effect.

For each innovation that Steve Johnson explains, he does so using stories, history, and science. He explains the main innovation, then it's children innovations (for example: sound, telephony, speakers). By linking children innovations with the main innovation, he is able to create clear linkages in the reader's mind, so that there is total engagement throughout each innovation he is trying to explain.

Steven Johnson makes many common observations about the six innovations he highlights. Namely that they trigger a series of other innovations, are placed at a time in history that they may be seen as inevitable, and that the innovators themselves had often worked for a series of several years prior to actually coming up with the innovation. That is: there wasn't really a lightbulb moment for these innovators. Infact, Steve Johnson even highlights that Edison himself didn't really have a lightbulb moment when he came up with the lightbulb!

Personally, what connected to me the most was the invention of time or more specifically how we measure it. There comes a (point in)time in every Software Engineer's life that they have to deal with time and time zones. Whether it be technical debt because a system has grown from one time zone to multiple or making data structure decisions for new code. Steve Johnson explains the very early problems associated with the measurement of time using pendulums and the synchronization and standardisation across geographical areas. He creates a thorough and clear image in the reader's mind about the technologies starting from the sundial, to the pendulum, to quartz, and finally atomic time that we can see from our phones today. At the end of reading that chapter I thought to myself I'm so glad people have already developed all this time stuff and open sourced it!

This book strikes a good balance between storytelling, science, and history. It's a book that can be read in a relaxed setting and isn't a hard read. If you find that you want to delve into a specific area or innovation in more detail, Steve Johnson has sufficient footnotes for this. In conclusion, I would recommend you read this book as you'll stay engaged while learning a bit about science and history.


Popular posts from this blog

from zero to production in eighty days

When I mean zero, I literally mean zero. A brand new project, a PO that's new to IT, no existing processes in place and a small team of four including myself and the PO.

The departmental organisation we were working for doesn't have any developers, scrum masters, product owners working for them. Everything they did was either done by another department or outsourced completely.

This is a story how we went from zero to production in eighty days.

My first time speaking at a conference

Since time immemorial we humans have valued the art of public speaking. Today, I want to share with you my experiences in speaking at conferences for the first time. Recently, I spoke at both DDD Melbourne and DDD Perth. Both of which were positive experiences that I learnt a lot in.

Have You Ever Produced Negative Value in a System!?

As developers we encourage our product owners to order the priority of their backlog in order of value. However, every time a new feature is implemented by a development team, there is a certain degree of risk associated with the introduction of that new code. Namely, risk of breaking another part of the product and maintenance cost. When a development team pulls in a new feature to implement there is a certain acceptance of this risk. In many cases, the risks that arise due to additional code complexity doesn't justify the value added by the new feature itself, so the development team can start implementing it.

Are there scenarios where the value added to a software product can be negative though?