The cover image for this post is by Unsplash user Susan Q Yin
This blog post was written by Jamie.
Introduction
Just like my post from last year, I wanted to talk through the books that I’ve read in 2021 as part of RJJ’s continual learning programme. 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 at RJJ.
Note: Only a few of the books that I have listed here were actually published in 2021, 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 here:
The 2021 List
- API Security in Action
- Alice and Bob Learn Application Security
- Cybersecurity ABCs
- The Programmer’s Brain
- Software Craftsmanship
- The Five Dysfunctions of a Team
- NPR’s Podcast Start Up Guide: Create, Launch, and Grow a Podcast on Any Budget
- Essentialism
- The Life-Changing Magic of Tidying Up
- If I Understood You, Would I Have This Look On My Face?
Clicking on a book title will take you directly to the section of this blog post about it.
The books are not listed in the order in which I read them. Unlike last year, I have chosen to list these books with the technical books first and non-technical books after them. This is because my focus for 2021 was to improve my technical abilities and understanding first, then improve my business knowledge second.
Book 1: API Security in Action by Neil Madden
Security and writing secure code are two things which I wanted to cover this year, as it seems that daily occurrences of security breaches have become the way of life. So I wanted to start off with a book about writing secure code. API Security in Action delivers exactly this.
Whilst it’s a book written with Java (and Spring) in mind - and I focus more of C#, .NET, Python, and Go technology stacks - all of the principles that Madden includes in his code are backed up with very compelling and well researched theory. As with all of the “In Action” books from Manning, you are taken from no code to a finished application. In this instance, you build a WebAPI in Java with Spring using JWTs, but Madden also covers topics like constant time string comparisons, and IoT considerations.
Whilst this book is suitably dense, there is something here for every developer - regardless of the technology stack that you work in. I would definitely recommend this as a “getting your hands dirty, building something with best practises” type of book.
You can find out more about API Security in Action by Neil Madden at Goodreads.
Book 2: Alice and Bob Learn Application Security by Tanya Janca
I absolutely love the direction that Tanya takes in teaching Application Security in this book.
This is a book which focusses on teaching things like OWASP security best practises for Web APIs and Supply Chain attacks
interestingly, I read this book shortly before the investigation into the SolarWinds supply chain attacks
Whereas API Security in Action focusses on a very practical application of the same principals, Alice And Bob Learn Application Security has more of a theoretical background; as such it doesn’t deal with the exact technical implementation details on how to secure your applications from every type of attack that it mentions. As such, this book feels very much like a theory primer for the points raised in API Security in Action; making them perfect for each other.
Also, I had the excellent good fortune to interview Tanya about her book, shortly after it was released - here is a link to that interview.
You can find out more about Alice and Bob Learn Application Security bt Tanya Janca at Goodreads.
Book 3: Cybersecurity ABCs by Dr. Jessica Barker, Adrian Davis, Bruce Hallas, and Ciarán Mc Mahon
Do not let the fact that this book is rather short fool you into thinking that it is somehow inferior, as it cuts right to the matter at hand: how to get your organisation on-board with Cybersecurity by implementing Awarness, Behaviour, and Culture Change (the ABCs of the title).
Using research that they have undertaken, and leveraging bleeding edge research done by others, Dr. Barker et al. put forward several very detailed steps to achieve the changes in awareness, behaviour and culture which are required in order to boost cybersecurity training uptake in your organisation (and those of your customers and clients). The book is focussed specifically on the people of an organisation and how they can approach cybersecurity; taking aware the fear, stigma, and confusion about what cybersecurity is and how it should be best implemented.
I firmly believe that the first three books on this list should all be read, as a set, and the lessons learnt should be applied to all professional endeavours by all developers. After all, you could build the most secure application in the world, but if the people who are using and supporting it are not taking cyber security seriously, you’ll soon have a security breach.
You can find out more about Cybersecurity ABCs by Dr. Jessica Barker, Adrian Davis, Bruce Hallas, and Ciarán Mc Mahonen at Goodreads.
Book 4: The Programmer’s Brain by Dr. Felienne Hermans
Imagine the situation: you want to learn a new programming language or technique. So you go and buy a book on it (or take a course), and you can feel the information going in but not sticking around. What’s happening is that the new information isn’t going into your long-term memory.
Dr. Hermanns' book is all about showing you how the brain works so that you can make that new information go into your long-term memory; and she uses a series of metaphors that almost all developers know and appreciate: how storage, RAM, I/O, and CPU caches in your computer work. I’m a huge fan of metaphor as a teaching aid, and the ones used in this book are fantastic.
I particularly enjoyed learning what
2 2 2 2 2 T n
(which is APL code) does, and how best to learn (and remember) terse code like it. There are lessons on chunking, spacial memory, and why rules like “methods should be no longer than 10 lines” actually make sense - all using the very latest in neuroscience research.
Reading this book will give you the double-whammy of being able to write code which is easier to grok, but also help you to learn codebases, frameworks, languages, and APIs much quicker.
You can find out more about The Programmer’s Brain by Dr. Felienne Hermans at Goodreads.
Book 5: Software Craftsmanship by Pete McBreen
Just writing good code is not enough; i order to have a truly remarkable career we need to become craftsmen - this is the thesis of Pete McBreen’s book.
Personally I prefer the gender neutral term "Artisan", as "Craftsman" doesn’t feel as inclusive, as such I’ll use it for the rest of this blog post
Becoming a Software Artisan is about more than just writing lots of good quality code. McBreen posits that a Software Artisan should learn from their peers in a similar way to how European guild systems worked:
- You enter as an Apprentice, knowing virtually nothing
- Journeymen take you under their wings and teach you the basics
"Journeyperson" might be a better, more inclusive term; if a little awkward at first
- Artisans add to the knowledge that the Journeypersons and add to their knowledge
- A Journeyperson will apprentice themselves with several Artisans, creating new works and helping Apprentices
- Artisans will approve the work of the Journeypersons until they have produced their “Masterpiece”
- Upon creating their Masterpiece, the Journeyperson will achieve Artisan status
- All Artisans are required to train Journeypersons and Apprentices
McBreen uses this framework to describe how developers, regardless of where they are on their journey, should apply these rules in order to better themselves, those around them, and the craft of software development. And this is similar to a framework that I have started using this year in order to learn more and help the next generation of developers.
You can find out more about Software Craftsmanship by Pete McBreen at Goodreads.
Book 6: The Five Dysfunctions of a Team by Patrick Lencioni
Last year’s list had a business book which used metaphor and allegory to teach it’s lessons
that book was Who Moved My Cheese - Dr. Spencer Johnson
and this year’s entry which use allegory is The Five Dysfunctions of a Team. I was prompted to read it when I saw a post on LinkedIn by Rion Williams - a person that I have a lot of respect for, and one of the many amazing people that I have met via the Coding Blocks Slack group.
I found this book to be a very quick read, and flew through half of it in an evening. It talks about the following five dysfunctions and how they can bring about poor synergy, create toxic work environments, and can destroy teamwork with politics and infighting:
- Absence of trust
- Fear of conflict
- Lack of commitment
- Avoidance of accountability
- Inattention to results
Lencioni posits that by tackling these five points, a leader can create an environment where the team can become a gestalt entity: becoming much more than the sum of it’s parts and achieving greatness. He does this through the fictional telling of a new CEO taking her direct reports on a series of work related retreats.
You can find out more about The Five Dysfunctions of a Team by Patrick Lencioni at Goodreads.
Book 7: NPR’s Podcast Start Up Guide: Create, Launch, and Grow a Podcast on Any Budget by Glen Weldon
It’s no secret that I enjoy creating and consuming podcast content
my personal twitter account is called @podcasterjay, by the way
and as I’m always looking for ways to create better content (and I’m a big fan of NPR’s podcast Pop Culture Happy Hour - Glen is one of the hosts of this show), it was inevitable that I would end up reading this book. I managed to get a copy very shortly after it was first published, and read it in one sitting. As soon as I did, I started reaching out to other podcasters that I know, telling them about this book.
This book is obviously about podcasting, but the advice that Glen shares can be used for almost any creative endeavour:
- Know what your creation will be
- Know who it is aimed at
- Start creating the thing
- As you are working on it, look at ways to improve
- Marketing, marketing, marketing
- It’s ok to get better slowly
- It’s also ok not to know everything at the start
- Know about the legalities surrounding your creation
there is a whole section of the book devoted to how including copyrighted material in a podcast likely isn’t "fair use" unless you are actually providing commentary on it - and from a top copyright lawyer, too
I would recommend this book to anyone who either wants to start a podcast or someone who wants to take a pre-existing podcast and make it better.
we have two separate blog posts with lessons learnt from podcasting, by the way
You can find out more about NPR’s Podcast Start Up Guide: Create, Launch, and Grow a Podcast on Any Budget by Glen Weldon at Goodreads.
Book 8: Essentialism by Greg McKeown
Saying “no” to anything is hard to do, but saying no to someone who has a direct requirement on you achieving some goal for them is even harder. Kevin Mitnick built a career out of exploiting people’s weakness around not wanting let people down (even strangers) and called it “Social Engineering”.
In Essentialism Greg McKeown teaches the “Way of the Essentialist”. This is a way of completing more of the right kinds of tasks rather than just getting more done - simply getting more done in a period of time won’t necessarily make you more productive.
McKeown posits that Essentialist complete their “right kind of tasks” by identifying those tasks which are absolutely essential in achieving a goal, and systematically eliminating every other task; that way your contributions are focussed specifically on those which can get you to achieve the goals that you set for yourself.
This is useful to developers because quite often our applications will suffer from Feature Creep - where we start adding things because we might need them in the future. It also helps us to remember the tenets behind Red-Green-Refactor:
Write a failing test; write JUST ENOUGH code to make it pass; refactor the code; repeat
It is often too easy to add new features as we are writing the code. This doesn’t help us to achieve the goal of writing the code that we are supposed to be writing, it slows us down, and it creates code that we must maintain even though it doesn’t solve the problem we are trying to solve. Only ever write the code which will achieve the goal, and no more. More code is more room for bugs to appear.
You can find out more about Essentialism by Greg McKeown at Goodreads.
Book 9: The Life-Changing Magic of Tidying Up by Mari Kondo
This is a book recommendation which I think my seem like it comes out of left-field, especially as a recommendation from a software developer to other software developers. But you’ll soon see why.
In case you haven’t heard of it, the KonMari method is made up for six steps:
- Commit yourself to tidying up.
- Imagine your ideal lifestyle.
- Finish discarding first. Before getting rid of items, sincerely thank each item for serving its purpose.
- Tidy by category, not location.
- Follow the right order.
- Ask yourself if it sparks joy.
And while both “sincerely thank each item for serving its purpose,” and “ask yourself it it sparks joy,” may sound a little too esoteric for a software developer to do, I feel as though all six of these steps should be followed as we write code.
As you reach the end of writing some function, method, or chunk of code, you should reflect upon it (we usually call this refactoring) and you should follow each of the above steps - with some slight changes to the wording, of course:
- Commit yourself to refactoring - you wont be writing any new functionality, just tidying up recently created code
- Imagine the ideal code - you need to start imagining what the code should look like when it is finished
- Finish discarding first. Before getting rid of code, sincerely thank each line or block for helping you to discover the refactored code.
- Tidy by method or function, not line of code - or refactor on a functional level, looking at each function, method, or code block in turn, rather than focussing on individual lines
- Work from the entry point of your code through to the exit point - “Begin at the beginning,” the King said gravely, “and go on till you come to the end: then stop."
- Ask yourself if it is required in order to provide the functionality you are looking for - you should only ever write the code which is required in order to solve the problem or provide the functionality
I have altered some of the wording in the KonMari method to fit refactoring (which are italicised), and added some supporting statements (which are in bold). Number 5 in this list contains a quote from Alice in Wonderland:
"Begin at the beginning," the King said gravely, "and go on till you come to the end: then stop."
As I said, the KonMari method is essential to well written code. That is code which does precisely what it should do and no more. And pairing The Life-Changing Magic of Tidying Up with Essentialism will help to reinforce these lessons even further.
You can find out more about The Life-Changing Magic of Tidying Up by Mari Kondo at Goodreads.
Book 10: If I Understood You, Would I Have This Look On My Face? by Alan Alda
I’m a huge fan of Alan Alda - and not just because of the TV show MASH. I really enjoy listening to his podcast Clear and Vivid with Alan Alda. Both has podcast and this book are about one thing: connecting and communicating in the clearest way possible.
As a software developer, it is part of my job to explain things to other people. This can be either via code, comments, or conversation with other people. Each of those settings have completely different contexts, rules, and expectations of those involved. Discussing a deeply technical matter surrounding database shard propagation with the average CEO of a company will likely produce a look of glass-eyed confusion on the CEO’s face
unless you are talking to the CEO of a database sharding company, of course
And commenting about WHAT code is doing rather than the WHY is likely to cause derision from your fellow developers. Consider the following two code blocks:
// reading the contents of someFileName as Hexadecimal
var someStringOfHexCharacters = ReadFileContentsAsHexadecimal(someFileName);
// getting the 85 character out of the string
var byte = someStringOfHexCharacters[85];
// ReadFileContentsAsHexadecimal returns a character array, representing
// the contents of the file temperatureOutput as hexadecimal characters.
// We need to load the file as Hex characters as we'll be operating on
// the raw values
var characterArray = ReadFileContentsAsHexadecimal(temperatureOutput);
// Character number 86 of the array is the control code that we need to
// check for before venting the nuclear reactor. The array is 0 indexed.
// Currently (as of Dec-29, 2021), if this value is 0x25 then we need to
// vent, otherwise we do not need to vent.
// This is the control code returned by the temperature gauge installed a
// the reactor's core. See: "Reactor Core Temperature Array Codes" on
// the internal development Wiki for more details.
var controlCode = characterArray[85];
The above code is very contrived. The comments and variable names in the first code block tell you what each line is doing, whereas the comments and code in the second block tell you why each line is doing what it is doing and where to find more information. Most of the time, the why is more important, as the code itself tells you what it is doing.
Alda spends a lot of time in his book giving exceptional examples of when he (and the Alda Centre for Communicating Science) have helped scientists to explain deeply technical scientific research in the simplest, most easily grokkable way. After all, Einstein is thought to have said:
Everything should be made as simple as possible, but no simpler
You can find out more about If I Understood You, Would I Have This Look On My Face? by Alan Alda at Goodreads.
Honourable Mentions
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 that I have read this year:
- Lock-On Volume 2 by Lost in Cult
- An Atypical ASP.NET Core 5 Design Patterns Guide: A SOLID adventure into architectural principles, design patterns, .NET 5, and C# by Carl-Hugo Marcotte
- The Courage to Be Disliked: How to Free Yourself, Change your Life and Achieve Real Happiness by Ichiro Kishimi
- The Ultimate History of Video Games, Volume 1 by Stephen L. Kent
- The Power of Boredom: Why Boredom is Essential to Creating a Meaningful Life by Mark A. Hawkins
- Itchy, Tasty: An Unofficial History of Resident Evil by Alex Aniel
- Play: How It Shapes the Brain, Opens the Imagination, and Invigorates the Soul by Dr. Stuart M. Brown
- Drive: The Surprising Truth About What Motivates Us by Daniel H. Pink
- Shape Up: Stop Running in Circles and Ship Work that Matters by Ryan Singer
In Closing
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 best-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, via the lessons taught in The Goal (by Eliyahu M. Goldratt) and Kaizen (by Masaaki Imai).