The cover image for this post is by Unsplash user Daniel
This blog post was written by Jamie.
At RJJ we take pride in the fact that we encourage our colleagues to continually learn by offering them resources, training, and a budget for self-directed learning. I’ve often said:
The moment you stop learning, you’re already two weeks behind
Medicine, engineering, law, and development are industries which require those who work in them to be continually learning. Whether that is keeping up with the latest breakthroughs or revisiting previous areas of expertise in order to keep our skills fresh, it’s important to be looking around at what else is happening in the industry that we work in. With that in mind, I wanted to discuss some of the books that I had read this year as part of my continual learning journey.
Note: Only a few of the books that I chose were actually published in 2020, but they are all books that I have read this year.
Each book will be presented with reasons as to why I picked it, but if you want to “skip to the end” and see the list without the reasons then you can click here.
The books are not listed in the order in which I read them. The order that I’ve listed them in takes the reader from non-technical/business through to technical, with a final few on business.
Book 1: Who Moved My Cheese - Dr Spencer Johnson
This is a wonderful story-within-a-story, which serves as a metaphor for dealing with unexpected change - something we deal with on a daily basis in both life and work. The characters in the story-within-a-story are mice who live in a maze. Their everyday lives are turned upside down when their supply of cheese is suddenly moved, and they have to deal with what to do next.
This is a perfect allegory for life, work, love, and money. It fits perfectly in the world of development because it attempts to teach us how to deal with unexpected changes - from “can this button be blue?” to “this is great, but what I actually wanted was…” Some people that I’ve recommended this book to have baulked at the cartoony presentation (“I’m not going to read a book about anthropomorphic mice”) and some tried to take the struggle that the mice go through and intellectualise it too much (“it’s an allegory for,” then they would push a political agenda). But I think that’s one of the great things about this book, in that it’s unintentionally divisive - making those readers sound almost exactly like the “Hem” and “Haw” characters of the book.
This is an extremely short book, but the points it makes don’t really need that much time and space to explore. Then again, I have the sequel (“Out of the Maze: An A-Mazing Way to Get Unstuck”) on my list of books to read next year, so perhaps there are more points to cover.
You can find out more about Who Moved My Cheese at Goodreads.
Book 2: Kaizen: The Key to Japan’s Competitive Success
You might be wondering why I spent the time to read a book from 1986 about Japanese business practises. If you’ve ever heard of Agile, Scrum, Lean, The Toyota Production System, or DevOps then you’ve heard of Kaizen.
As someone who speaks Japanese, I had wanted to learn more about Kaizen since I first heard about it 5 years ago - just on the cusp of the DevOps revolution. “改善” (kaizen) is often translated as “improvement”, but the Kaizen movement is more about continual improvement. By allowing everyone who is involved with an activity the opportunity to speak up about ways that the activity can be improved, you allow for infinitely more room to improve.
The canonical example of this - and one which is used in the book - is that of a tool production line: There are 10 engineers, each working at their workstations, and they are all involved with creating a single product. When the first engineer is finished with their work, they pass the product to the next engineer. When the final engineer has finished their work, it is passed to a quality assurance engineer, who can either pass or fail the product. If it is failed, then the product goes back to the start of the production line and each engineer will have to redo their work, in turn.
One of the many things that Kaizen teaches is that anyone along the assembly line can stop the assembly of the product if they spot an issue with the quality of the product, effectively holding creation of all products behind it. You might think that this would cause chaos, but it actually leads to a much more well engineered product. It means that everyone involved in the creation of the product provides immediate feedback on the work which has happened before it reached them.
We know that this is true as:
Most defects end up costing more than it would have cost to prevent them. Defects are expensive when they occur, both the direct costs of fixing the defects and the indirect costs because of damaged relationships, lost business, and lost development time
So providing those constant feedback loops (something which is mentioned in both The Phoenix Project and The DevOps Handbook) is essential if we want to be able to create the best products that we can.
Whilst this book is presented as an introduction to The Way from a business perspective, the points raised are immediately applicable to developers. The PDCA (Plan-Do-Check-Act) and Toyota Production System had a direct impact on, and are part of the lineage for, DevOps, Agile, Scrum, and Lean. Whilst you might not be able to convince your employees to be able to give you certificates which will lead to discounted mortgage rates (something which Toyota offered at the time of the book’s writing, and which the author Masaaki Imai talks about), you might just be able to convince them to adopt some of the other aspects of Kaizen.
You can find out more about Kaizen: The Key to Japan’s Competitive Success at Goodreads.
Book 3: Man, Pub, Pint - "Drinking Man"
This book was written by a friend of mine, under a pseudonym. I’m not sure why he chose to use a pseudonym, but that’s the author’s prerogative, I suppose.
Man, Pub, Pint provides an introduction to the way that the Internet works from the perspective of a man who wants to go to the pub and drink a pint of beer. The metaphor used is wonderfully approachable even if you don’t drink - exchange the “pub” for a restaurant, and the “pint of beer” for a meal, and the entire text is the same - and makes understanding how the OSI model, what DNS is and how it works, and even provides some useful hints for troubleshooting your network connections.
With almost all of development tasks (and the products we create) making use of networking and the Internet backbone, I feel that it is incredibly important for developers to understand how it works. This book does just that. Whilst it covers the technicalities of how it all works, and certainly doesn’t shy away from using the correct terms and describing them, its use of metaphor and allegory to describe how they work is fantastic. The target audience for this book is not developers, engineers, or even computer “power users”; it’s aimed at anyone who has said to you:
You work in computers, can you fix my Internet?
Book 4: Modern Web Development on The JAM Stack - Mathias Biilmann & Phil Hawksworth
Almost every company has a website, and almost none of them require a massive server infrastructure. I don’t just mean brochureware websites either, the majority of online stores (especially those which are speciality ones) don’t actually require a lot of server-side infrastructure.
Some examples that I have been involved in are
There are more examples over at the JAM Stack examples page
So what makes the JAM stack so great? Server infrastructure can be expensive, especially if you’re using cloud provided infrastructure, and web browsers more powerful than they ever have been. So why not push the “heavy lifting” over to the browser? In the .NET world, we’re seeing that with client-side Blazor.
By leveraging thin APIs which do one thing and building a front end which ties them all together, we’re not only achieving that lofty goal of utilising Microservices, but we’re actually de-coupling our application from a single server. We also lower our actual runtime cost for the entire application.
I honestly believe that, for the majority of company websites, they should be leveraging the JAM stack rather than a bloated, server side stack simply because “that’s the way we’ve always done it.”
something something who moved my cheese 😛
You can find out more about Kaizen: The Key to Japan’s Competitive Success at Modern Web Development on The JAM Stack
Book 5: ASP .NET Core in Action - Andrew Lock
As a .NET Developer, I’m always looking for ways to expand my knowledge of everything that .NET provides - and it provides an awful lot. When I interviewed Andrew for The .NET Core Podcast, I wanted to do so for two reasons:
- he has one of the best blogs about ASP .NET Core
- he had just finished writing the first edition of ASP .NET Core in Action
I had actually read Andrew’s book shortly after interviewing him but wanted to revisit it because there is a lot of information in it. This is the same reasoning behind my yearly revisit of Code Complete 2 and C# in Depth - something that I recommend all .NET developers do. Whilst it is information-dense, it is a refreshingly easy read. It covers everything that you need to know (both good and bad) in order to create applications with ASP .NET Core, and the density of the information included in the book shows just how much research Andrew put into writing it.
Just as with the other titles in Manning’s “in Action” series, this book takes you through the steps required to actually build a real-world application and provides a lot of the background information as it goes.
You can find out more about ASP .NET Core in Action at Goodreads.
Book 6: The Pragmatic Programmer - Andy Hunt & Dave Thomas
There isn’t a lot that I can say about PragProg which hasn’t already been said by others, but I’ll try.
I actually read the 20th-anniversary version of this book, which has expanded and re-visited sections from the original. It was this book which introduced the world to the benefits of rubber duck debugging, engineering Daybooks, plain text (over arbitrary formats), and the actual work of software engineering: converting specifications into working code.
It’s a book which teaches its readers that they must take pride in the work that they produce, in the same what that a craftsman would, but also approach it in a pragmatic way. This is because modern software development is a combination of art and science. As such, it needs to be approached with the teachings from both. The book also teaches the importance of both being a mentor and a mentee: both asking for the advice of someone else, and giving back.
There’s not much else to say about this book other than if you’re a developer and haven’t read it, then you should read it.
You can find out more about The Pragmatic Programmer at Goodreads.
Book 7: Framework Design Guidelines - Krzysztof Cwalina, Jeremy Barton & Brad Abrams
Why would I, as a .NET developer, be interested in a book about how the .NET team designed the .NET APIs? I feel like I shouldn’t need to answer that question.
This was a book which appeared on my radar halfway into the year. In fact, it appeared just as the third edition had gone to print (it was released on June 18th, 2020), but as soon as I received my copy of it I started reading it. Each day, I read a chapter or so and found a nugget of information. From things like:
On of the biggest misconceptions about exceptions is that that are for "exceptional conditions." The reality is that they are intended for communicating error conditions. From a framework design perspective, there is no such thing as an "exceptional condition." Whether a condition is exceptional or not depends on the context of it’s usage, but reusable libraries rarely know how they will be used. For example,
OutOfMemoryExceptionmight be exceptional for a simple data entry application; it’s not so exceptional for applications doing their own memory management (e.g., SQL Server). In other words, one man’s exceptional condition is another man’s chronic condition
(emphasis is mine)
If you are a .NET developer or a developer of frameworks and libraries, then you need to read this book. The knowledge and experience presented in this book comes from the 20+ years of experience of each author and contributor of working on the .NET APIs.
You can find out more about Framework Design Guidelines at Goodreads.
Book 8: Clean Agile: Back to Basics - Robert C. Martin
Imagine that you were one of the 17 people involved in creating the Agile Manifesto. Now imagine that you’ve seen a cottage industry of pointless qualifications, training courses, and certifications spring up around the four sentences that you and the 16 signatories agreed upon:
Individuals and interactions over processes and tools; Working software over comprehensive documentation; Customer collaboration over contract negotiation; Responding to change over following a plan
There’s more to the Agile manifesto, but that is it boiled down to its core components.
Clean Agile is “Uncle” Bob’s answer to this, and the criticism which has been raised at Agile. The interesting thing is that the majority of critics of Agile are criticising what some of the signatories are calling:
The entire point of Clean Agile is to point out that what people think of Agile, the certifications, meetings upon meetings, process over people (I’ll leave finding the irony of that up to the reader) actually isn’t agile. Here’s a tweet of his from Jun 4, 2019:
And that’s just it: Agile is a way of measuring the progress of a team and feeding that progress back to the customer or client.
After reading this book, you might feel as though the way that a lot of companies have adopted “Agile” (quotes are intentional) is somewhere between “slightly incorrect” and “not even vaguely Agile,” and that’s because you’d be right.
You can find out more about Clean Agile: Back to Basics at Goodreads.
Book 9: Flawless Consulting: A Guide to Getting Your Expertise Used - Peter Block
Regardless of whether you have a job title and whether that job title has the word “consultant” in it or not, you should read this book. Why? Because you are a consultant. Whether you are an external consultant (what most people think of when they think of the words “consultant” or “contractor”) or an internal consultant (employees are internal consultants), you are working for a client (either a business or your boss) and you want your skills to be used. After all, that’s why you were hired, right?
Flawless Consulting focuses on the processes that you can adopt to help your clients find out the details of a problem that you’ve been brought in to solve, how to present them with the actual problem (what they think they need and what they actually need are often quite different), how to prove that you have completed the work to their specification, and how to follow up on that completed work.
Hopefully, you’ll agree that that sounds like it covers:
- Specifications gathering
- Acceptance test authoring
- Handing over the solution
- Feeding back with the client
If not, then I’ve likely not done a good job as a writer (which isn’t my main vocation). Either way, I’d recommend that you read this book anyway.
You can find out more about Flawless Consulting: A Guide to Getting Your Expertise Used at Goodreads.
Book 10: Rework - Jason Fried & David Heinemeier Hansson
DHH can be quite decisive, but I’m not sure it’s possible to disagree that he’s been involved with some of the fastest-growing startup ideas and services in the last 20+ years. And because of that, his no-nonsense guide to what worked for him and his partners cuts straight through the standard business advice.
This is an easily digestible book presented in very short sections - I wouldn’t even call them chapters because they’re so short. But that isn’t to say that they are light on detail; they are very, very dense yet quite terse. Very few words here actually say a lot. Presumably, this because the authors took their advice (“Focus on your product and the value it provides”) and applied it to writing.
One thing to note is that DHH and Jason Fried could be considered as very brave “go-getter” types, and what worked for them (the “hustle til dawn, damn the torpedoes, go after the gold and don’t settle for second best”) might not work for you. But their advice and examples are still very relevant all the same: get to the heart of the product and build that first, then add all of the bells and whistles IFF (if and only if) they are required and bring value.
You can find out more about Rework at Goodreads.
The 2020 List
- Who Moved My Cheese
- Kaizen: The Key to Japan’s Competitive Success
- Man, Pub, Pint
- Modern Web Development on The JAM Stack
- ASP .NET Core in Action
- The Pragmatic Programmer - 20th Anniversary Edition
- Framework Design Guidelines
- Clean Agile: Back to Basics
- Flawless Consulting: A Guide to Getting Your Expertise Used
The above isn’t the entire list of books that I had read this year (as part of my continual learning, or leisure reading). As such, I feel like I need to mention a few other titles, some of which I have read this year and some I have read in years past:
- Code Complete 2 - Steve McConnell
- The Phoenix Project - Gene Kim, George Spafford & Kevin Behr
- The DevOps Handbook: How to Create World-Class Agility, Reliability, and Security in Technology Organizations - Gene Kim, Jez Humble, Patrick Debois & John Willis
- Clean Architecture - Robert C. Martin
- The Goal - Eliyahu M. Goldratt
- Working Effectively With Legacy Code - Michael C. Feathers
- C# in Depth - Jon Skeet
- The Clean Coder - Robert C. Martin
- The Secrets of Consulting - Gerald M. Weinberg
Using the time and budget that RJJ provide for training and continual development, I feel as though I have been able to touch on a number of topics which lie either slightly adjacent to development or are directly related to some of the modern practises that we use in modern software development - even if they came from outside of the development industry. And I think that there are two key points here:
- the need to continually learn
- the need to look outside of one’s industry
By continually learning we can ensure that the knowledge we already possess is backed up and refreshed with new knowledge, we also build on that knowledge and are able to move in new directions because of it. By looking outside of our industry, we are able to see familiar problems in a completely new light and are able to appreciate novel (to us) solutions to those problems.
I always recommend that developers continually learn, and look outside of their industry (or there section of it) as there’s always something to learn and bring back to your work. After all, that’s how the DevOps movement started: applying the Toyota Production System to software development.