Continual Professional Development - 2023

The cover image for this post is by Unsplash user vnwayne fan

This blog post was written by Jamie.

Introduction

As is now the tradition, I wanted to take a moment at the end of the year to talk through some of the best books that I’ve read as part of my continuous professional development here at RJJ Software. If you’d like to read through my lists from previous years, you can find them all here.

I’m incredibly proud that we at RJJ offer all of our colleagues the chance to learn and grow via our CPD programme. And what sets us apart from most companies in the tech space is that we allow our colleagues the time and budget to learn whatever they want, with whatever resources they see fit. I like to force myself to slow down, so reading seemed right for me—I had also planed a little more international travel this year, and reading is more flight friendly.

I’m not just going to list each book in my top 10, I’m going to talk through why I picked it for this list, and some of my main takeaways from it. But if you want to skip over reading why I picked them, here is the entire list:

The 2023 List

1. A Philosophy of Software Design by John Ousterhout
2. Kill It With Fire - Managing Aging Computer Systems by Marianne Bellotti
3. Wabi Sabi — Japanese Wisdom for a Perfectly Imperfect Life by Beth Kempton
4. Atomic Habits: An Easy & Proven Way to Build Good Habits & Break Bad Ones by James Clear
5. Tomorrow, and Tomorrow, and Tomorrow by Gabrielle Zevin
6. The Rules of Programming - How to Write Better Code by Chris Zimmerman
7. The Infinite Game by Simon Sinek
8. The Art of Living by Thích Nhất Hạnh
9. Rising Strong by Brené Brown
10. Right Kind of Wrong - The Science of Failing Well by Amy C. Edmondson

Clicking on a book title will take you directly to the section of this blog post about it. And each book description links through to The Story Graph so that you can learn more about them.

Book 1. A Philosophy of Software Design by John Ousterhout

There are just three books on software development in this year’s list, and this is highly irregular for me—believe it or not—as lists from previous years have peaked at four books on development (in 2020), but average at two per year. But when I heard about Ousterhout’s book on software design, I felt that I had to read it.

I have to say that this book has a lot of great rules of thumb, for instance:

Sometimes an approach that requires more lines of code is actually simple, because it reduces cognitive load

Which is a fine example of what McConnel talks about in Code Complete: we write software for other humans to read, maintain, and alter. If we can’t understand a block of code, then it is not a simple design.

Consider the following trivial (and badly thought out) examples:

var results = await AllItems.
      .Asqueryable
      .Where(i => i.Cost > 5)
      .OrderBy(i => i.Name)
      .Select(kvp => kvp.Value)
      .ToList()
      .Sum();

vs:

var allItemsLazy = await AllItems.AsQueryable();
var relevantItems = allItemsLazy.Where(i => i.Cost > 5);
var orderedItems = relevantItems.OrderBy(i => i.Name);
var allValues = orderedItems.Select(kvp => kvp.Value).ToList();
var sumTotalValue = allValues.Sum();

Not only is does the second example present an easier cognitive load (a developer can reason about each line in turn), but it’s also easier to debug as a developer can put a break point on a line and can inspect the results of each line. And the icing on the cake is that the second version becomes the first version once it is JITed (Just-in-time compiled) by the C# compiler.

However, I would say that this is about as deep as the rules of thumb go, especially when compared to The Rules of Programming, which will learn about later. And I think that it’s worth knowing the following points (which Ousterhout admits to in interviews, and were collated by my friend Jim Humelsine):

• The book is based upon his personal experience, and teaching the course a total of 3 times.
• He has about 20 students in each semester.
• There’s only one course like this at Stanford: his.
• It’s limited in size, so only the best students get into it. So only the best of Stanford qualifies.
• It’s only 10 weeks long, so they can’t get into too much detail.
• There are 3 projects, but each project starts anew. They only see design principles in theory. They don’t have to maintain their own code over the 10 week semester. From what I can tell, they don’t have to maintain it for more than a few weeks before they get to the next assignment or the end of the semester.
• They don’t practice unit testing. The students balked at the idea.

This is not like the real world. They should have to maintain code, possibly code that wasn’t theirs to start with. They should work in teams. Maybe the teams get shuffled about 6 weeks in. The requirements should change too. Can their new design be flexible to not only add new features, but remove old ones?

So why did I include it in my list? Because the rules of thumb are still very important to know. And the points that Ousterhout brings up about software design throughout the book are all relevant, even when you know the above points. For instance:

If a software system is hard to understand and modify, then it is complicated; if it is easy to understand and modify, then it is simple.

Which seems perfectly self-explanatory, right?

You can read more about A Philosophy of Software Design by John Ousterhout at The Story Graph.

Book 2. Kill It With Fire - Managing Aging Computer Systems by Marianne Bellotti

Each of us in the software development/engineering industry will work with some form of legacy code, at some point in our careers—regardless of how you, personally, define “legacy code”, that is. Because of this, it is imperative that we all know how to deal with legacy code. Both Bellotti’s book and Working Effectively with Legacy Code by Michael Feathers should be required reading for all developers/engineers.

I’ve now read both Bellotti and Feathers, but preferred Bellotti’s book. Perhaps that’s because it was released more recently (2021), or perhaps it’s because it ended up on my reading list both as I was preparing to work on a very large legacy code base and preparing to interview M. Scott Ford about legacy code.

Bellotti presents a treasure trove of advice and salient points regarding legacy code throughout the book, such as this quote about what legacy code is, and how it differs from code which is simply old:

Simply being old is not enough to make something legacy. The subtext behind the phrase "legacy technology" is that it’s also bad, barely functioning maybe, but legacy technology exists only if it is successful. These old programs are perhaps less efficient than they were before, but technology that isn’t used doesn’t survive decades.

It’s all too easy to assume that something is legacy because it is old, and we tend to label it as such all too often. But being old doesn’t meant that it’s legacy. My personal definition of legacy is that there is a real, quantifiable, business-related need to replace something, but as Richard Campbell said in his appearance on an early episode of The Modern .NET Show:

Code which already exists is infinitely more valuable than code which exists in someone’s head, because it both exists and already works.

And Bellotti goes on to talk about how legacy modernisation projects are, at their code, projects which require wrangling cats—in the form of controlling how much of the existing solution is replaced:

The first mistake software engineers make with legacy moderinzation is assuming technical advancement is linear. With that frame of mind, anything built in older design patterns or with an older architectural philosophy is inferior to newer options. Improving the performance of an old system is just a matter of rearranging it into a new pattern.

Believing that everything is advancing linearly, and that your code will be “better” because it’s being written now vs the original code, which was written then, are two very dangerous beliefs to hold in our industry. There’s a reason why “if it ain’t broke, don’t fix it” exists.

Imagine being tasked with rewriting ping. Is it something that, fundamentally, needs to be rewritten? And if it is, how could you possibly go about covering every single corner case involved? Would your version of ping be better than the original simply because it’s written in Rust, go, or node?

You can read more about Kill It With Fire - Managing Aging Computer Systems by Marianne Bellotti at The Story Graph.

Book 3. Wabi Sabi — Japanese Wisdom for a Perfectly Imperfect Life by Beth Kempton

We often chase after perfection in all aspects of life and work, especially so with software development. And quite often that comes at the cost of stress and almost always leads to burnout. The perfectionist’s life is a difficult one, filled with struggle—especially in software development.

This is where Beth Kempton’s work on exploring the Japanese concept of Wabi-Sabi comes in. In her book, Kempton talks about all of the deep, meaningful lessons that we can take from the, often difficult to describe concept. But she starts with the core lesson of Wabi-Sabi, which is that of slowing down and not making yourself ill by chasing after perfection:

Put simply, wabi sabi gives you permission to be yourself. It encourages you to do your best but not make yourself ill in the pursuit of an unattainable goal of perfection. It gently motions you to relax, slow down and enjoy your life. And it shows you that beauty can be found in the most unlikely of places, making every day a doorway to delight

The thing about software development is that it’s a field which demands excellence of us at all times, whereas we should really be striving for balance and self-acceptance at all times. We are fragile beings, and we should focus on working within our constraints, not against them. We design software to run on specific hardware, yet we don’t live lives that are compatible with our own constrained bodies and abilities.

I’m, personally, quite glad that companies are starting to take the mental health of their employees more seriously—but I do wonder whether it’s the latest in a series of passing fads which can gain them quick brownie points and positive PR, because mental health issues aren’t something that can be fixed easily with a two hour seminar or an employee “health and wellness day”, but I digress.

Mental health awareness is something that I’m very passionate about, and it’s important to me that software developers—a group who fall prey to burnout incredibly easily—are supported throughout their career, especially since our industry seems to move a lot faster than most. It can be daunting to feel like you have to keep up with everything that is going on, and the fear of being left behind is very real. But as Kempton says:

We need to find ways to slow down, so life does not rush right past us. We need to start noticing more beauty to lift our spirits, and keep us inspired. We need to give ourselves permissions to let go of judgement and the endless pursuit of perfection. And we need to start seeing each other - and ourselves - for the perfect imperfect treasures that we are.

One of the things that I know a lot of software developers don’t do is appreciate their achievements. In a world of standups, burndown charts, constant movement towards the unattainable goal of “done” or “finished”, story points, and needing to ship more and more software, we often don’t look at what we’ve achieved in order to get to that point.

Japanese beauty is discovered in the experiencing, not just the seeing

As with a good movie or story, it’s not about the destination but the journey. Our lives will not be made any better by having reached the point of “done” or “complete” with the apps and services that we’ve made—truth be told, there’s no such thing as “done”, “complete”, or “finished” in software development. But we can make our lives better by focusing on the experiences and achievements it took to get to where we are.

You don’t climb a mountain only ot focus on the view from the top. We focus on the wonderful things we can see, learn, and experience on the way up the mountain, too.

We’ve been so busy trying to get the car up the hill that we have forgotten to turn around and look out over the beauty of all that lies all around us.

You can read more about Wabi Sabi: Japanese Wisdom for a Perfectly Imperfect Life by Beth Kempton at The Story Graph.

Book 4. Atomic Habits: An Easy & Proven Way to Build Good Habits & Break Bad Ones by James Clear

Firstly, if you haven’t read this book. Then I’d recommend buying a copy of it right now, and starting it as soon as you can.

I was told about this book in late 2022, by my physiotherapist. I had developed an issue with my left ankle which lead to me not being able to stand or walk for long periods of time, and I wanted to get it fixed. As part of my sessions, my physiotherapist would talk about my goals and what I wanted to achieve and James Clear’s book kept coming up.

This book will change your view on habits, and goals. It’s way better than [Charles] Duhigg [author of The Power of Habit].

I’d read Duhigg years ago and still try to manage my habits by thinking of them as the three step habit loop that he points out:

• cue (I walk past the fridge)
• action (I get a treat from the fridge)
• reward (I eat the treat)

Which is a pretty good way to think about habits and their power.

But Clear focuses less on the science of how habits work, and more on actionable things you can do everyday to create new habits or to help you reach new goals.

If you can get 1 percent better each day for one year, you’ll end up thirty-seven times better by the time you’re done. Conversely, if you get 1 percent worse each day for one year, you’ll decline nearly down to zero. What starts as a small win or minor setback accumulates into something much more.

(emphasis is mine)

Rather than talking about reaching for the overarching goal—say “I want to learn to speak Mandarin”—Clear talks about taking atomic (or very small) steps every day in order to reach that goal. So focusing on a single word or phrase for the day when learning a language, or focusing on flossing between two teeth each day; rather than the insurmountable task of “do the thing like a pro,” he advocates for “focus on the smallest possible, achievable goal.”

And this tracks in software development as much as it does in real life. There’s an argument for eating the frog, it’s also important to not overwhelm yourself and build things up, piece by piece. The last greenfield application I built was done piecemeal, rather than in one “big bang” step—and I’ll bet that yours was, too.

But Clear advocates for behavioural change rather than just achieving a set of goals. And the best way to do that, says Clear, is to create or join a culture which reinforces that change:

One of the most effective things you can do to build better habits is to join a culture where your desired behaviour is the normal behaviour. New habits seem achievable when you see others doing them every day.

If you are surrounded by fit people, you’re more likely to consider working out to be a common habit. If you’re surrounded by jazz lovers, you’re more likely to believe it’s reasonable to play jazz music every day.

Your culture sets your expectation for what is "normal." surround yourself with people who have the habits you want to have yourself. You’ll rise together.

…

Nothing sustains motivation better than belonging to the tribe. It transforms a personal quest into a shared one. Previously, you were on your own. Your identity was singular. You are a reader. You are a musician. You are an athlete. When you join a book club or a band or a cycling group, your identity becomes linked to those around you.

You can read more about Atomic Habits: An Easy & Proven Way to Build Good Habits & Break Bad Ones by James Clear at The Story Graph.

Book 5. Tomorrow, and Tomorrow, and Tomorrow by Gabrielle Zevin

This is the first, and only, fiction title on my main list this year. I like to include at least one piece of fiction in my list for the year. Last year, I included Iris Classon’s The Unlikely Success of a Copy-Paste Developer, and that’s a fictional tale with lots of software development stuff in it. But while Tomorrow… is a fictional tale about games development, it’s more about the people in the story than the process. It has a lot of easter eggs and references to real-life games development stuff (famous developers, incidents in gaming history, etc.) but it isn’t about any kind of software or development.

So why did I chose it for this list? Because it still has a lot of lessons for developers anyway. Such as:

To design a game is to imagine the person who will eventually play it.

Which is related to Simon Sinek’s book Start with Why: How Great Leaders Inspire Everyone to Take Action. If you don’t know who you’re building the software for (whether it’s a video game or a line-of-business application), then you can’t possibly understand why they need it. And if you don’t understand their why, then you can’t possibly build it with compassion.

Incidentally, we have publicly shared our why and our focus on compassionate software development. In fact, we feel that the software development industry as a collective needs to do better, and start focusing on compassion for our users. I’ve even written an entire episode of The Modern .NET Show about it.

You do and you can. I believe in you. And you aren’t failing, Sadie. Your game failed, yes. But you just told me: your company is succeeding. This is a company built on your technology, your good judgement, your labors. Embrace that.

In this quote, Sadie (the main character) is talking with her mentor (Dov) about a game that she created; she is lamenting the fact that the game didn’t sell well. She has conflated the game failing to reach critical success with personal failure. What Dov says here is entirely correct.

We often conflate the failure of a product or project with personal failure. Dov’s remark here about the company and technology that Sadie has built should be the focus. Without these successes, Sadie wouldn’t have been able to create the game which failed. We often don’t see the successes which lead to a failure, and we should look around everyone once in a while so that we can see what we have achieved.

Wood for the trees and all that.

You can read more about Tomorrow, and Tomorrow, and Tomorrow by Gabrielle Zevin at The Story Graph.

Book 6. The Rules of Programming - How to Write Better Code by Chris Zimmerman

I’ll hit you with the tl;dr for this book before sharing my insights and quotes from it: the core idea of this book is that Zimmerman wants the reader to keep their code as simple as possible. And this makes sense when you realise that he and his team develop incredibly complex video games entirely in C++.

The best way to implement a solution to any problem is the simplest one that meets all the requirements of that problem. The best code is the simplest code.

Im previous years, I’ve talked about the importance of reading books about technologies outside of your day-to-day languages and stack. Regardless of the technology stack you use, they’re all trying to solve the same problem (“alter the finite state machine that is the computer, such that it will accomplish some task”) and in (almost) the same way.

So A C#/.NET developer learning about C++, Java, go, Node, or Python is always a positive, because there will be something which always applies, regardless of the tech stack. And Zimmerman embraces this by offering an appendix for Python developers, where he covers the basics of how the code snippets found throughout the book might look when translated to Python.

Zimmerman doesn’t just limit his advice to “keep things simple, ok?” Rather, he spends time talking about naming conventions, and why your team should have and stick to them; discussing cognitive load; complexity of the problem to be solved, and how it’s important to think about whether the complexity is actually required; how DRY (Don’t Repeat Yourself) is often not very useful; and how premature generalisation is a bad thing.

When you’re holding a hammer, everything looks like a nail, right? Creating a general solution is handing out hammers. Don’t do it until you’re sure that you’ve got a bag of nails instead of a bag of screws.

It’s also interesting to me that, in the books introduction, Zimmerman makes it very clear that the book isn’t a list of rules that every team must adopt in a dogmatic way. He tells the reader that they should actually take some time after reading each rule, and the rationale behind it, to decide whether it’s a good fit for the team that they are on or the project that they are working on. Because of this, it makes this book perfect for a work-based book club; teams can read this book, one rule at a time, and come together to discuss each one over a lunch-and-learn or similar.

You can read more about The Rules of Programming - How to Write Better Code by Chris Zimmerman at The Story Graph.

Book 7. The Infinite Game by Simon Sinek

As with his other books, The Infinite Game is about the human side of business and company culture. but what is an infinite game? Well, in order to talk about an infinite game, we need to talk about a finite game and mindset first:

A finite-minded leader uses the company’s performance to demonstrate the value of their own career. An infinite-minded leader uses their career to enhance the long-term value of the company… and only part of that value is counted in money.

Sinek builds on his work in both Start With Why and Leaders Eat Last by focusing on finding the why of the team (introduced in Start With Why) and building trust and cohesion via the “selfless hormones” (introduced in Leaders Eat Last), and expands on the work of James P. Carse’s Finite and Infinite Games.

A finite game is played for the purpose of winning, an infinite game for the purpose of continuing the play

The infinite games in both business and life are about making sure that everyone can continue to play—whether that’s your competitors in business, a neighbour, a friend, or someone you have animosity towards. The only way that society works if if we play the infinite game.

If the current leaders are more focused on making their plan as big as possible, then, like a weed, it will do whatever it needs to do to grow. Regardless of the impact it has on the garden (or even the long-term prospects of the plant itself).

And a “leader” doesn’t need to be a CEO, or even a Project Manager. They can be anyone that someone else looks to be guidance or advice—a Mother, Father, Brother, friend, or colleague. As such, it is the responsibility of all leaders (and we’re all leaders, in one way or another) to ensure that we’re allowing the game ot continue. And the only way to do that is to play the infinite game.

Along the way, Sinek talks about building circles of safety, a place and time when everyone involved feels that the psychological safety required for them to be vulernable—all of which are things that Brené Brown also teaches.

A Circle of Safety is a necessary condition for trust to exist. It describes an environment in which people feel psychologically safe to be vulnerable around their colleagues. Safe to admit mistakes, and, of course, ask for help with the confidence that others will support them instead of using that information against them.

Without the psychological safety to speak up about mistakes (regardless of whether they were the cause of the mistake), they will be left to fester and get worse. A small accounting issue might be bad today, but it could bring a company to it’s knees in a few months or years. We’ll see another example of how important this is in a few books time.

You can read more about The Infinite Game by Simon Sinek at The Story Graph.

Book 8. The Art of Living by Thích Nhất Hạnh

As important as it is to spend time learning about technology, business, and interpersonal skills, it’s as important to look inside and learn more about oneself. And that’s why I include a book by the late Thích Nhất Hạnh on my list every year.

Some of Thích’s writing can seem a little too esoteric or dense for the some readers, but I believe that this book and his book on anger are two of the most approachable of his works; they also deal with very important things that almost all software developers face on a daily basis: anger and too much thinking.

We cannot deny that there is thinking. It is clear that thinking is taking place. Most of the time the problem is that too much thinking is taking place—thinking about yesterday, worrying about tomorrow—and all of that thinking takes us away from ourselves and from the here and now. When we are caught up in thinking about the past and the future, our mind is not with our body; it is not in contact with the life within us and around us in the present moment.

And overthinking can lead to distraction, which is something that we do not want as it can lead to us building complicated systems when a simple one would do (see my thoughts on The Rules Of Programming, above). And complexity is almost always a bad idea; there’s a reason why the KISS principle exists.

A reduction in complexity goes against everything that the, so called, “old guard” of developers stood for: “they can’t fire me, because I’m a knowledge silo. I know how everything works.” Job security through complexity and obscurity is very quickly becoming a thing of the past. With the advent of AI tools, we can have a complex codebase or process explained to us in moments. That’s not to say that developers aren’t needed, but more that knowledge silos are definitely a thing of the past.

According to impermanence, we change from one day to the next. We are not exactly the same person, but we’re not exactly a different person either. The me yesterday is different from the me today.

And the reduction in complexity, sharing of knowledge, and removal of knowledge silos goes hand in hand with something that Thích backs me up with here: the you tomorrow is not the same you as today, and they are not the same you as yesterday. So in six months time, when you come back to the code you wrote today, you won’t have the all of the context required for you to understand it. Because you’re not the same person.

And this fits with another of the books from earlier in this list: Wabi-Sabi

Change is inevitable, so trying to hold on to the past or present is pointless. Be open. Your life is happening right here, right now.

You can read more about The Art of Living by Thích Nhất Hạnh at The Story Graph.

Book 9. Rising Strong by Brené Brown

It’s no secret that I’m a big fan of Brené Brown. References to her work appear all over the RJJ Software website and our internal documents because I feel that her work on compassion, empathy, vulnerability, and courage are incredibly important for any career or walk of life.

Rising Strong starts with a lot of definitions, but the most important one was that of vulnerability:

Vulnerability is not winning or losing; it’s having the courage to show up and be seen when we have no control over the outcome. Vulnerability is not weakness; it’s our greatest measure of courage.

The ability to be vulnerable is the number one skill that I look for in new hires, interns, and apprentices. It’s right up there with willingness to learn. And that’s because if a person isn’t willing to be vulnerable, then they can’t be courageous. Imagine the situation:

Jane is a new intern at ACME Co. She has never worked for a big corporation in her life but has been thrown in at the deep end. Her job now requires her to complete tasks she’s never done before, but also to use software that she has never seen before.

If she weren’t vulnerable, she wouldn’t be able to either explore the processes and software to figure out what needs to be done, or to seek out help and say, “I don’t know what I’m doing.” Both of those actions require a great deal of vulnerability and courage.

At an earlier stage in my career, I was in a project meeting with a client and they brought up a new requirement, one which required knowledge that the development team didn’t have. I looked around the room and saw a lot of nodding heads, but no one asking questions. So I raised my hand and said, “ok, I’ll ask; since no one is going to…” and asked about the new requirement.

Rising Strong is about accepting that vulnerability, building the courage to speak up, and having strong enough psychological safety measures such that, when we do raise our voices, we can be heard and out view points listened to.

People aren’t themselves when they’re scared.

Brown doesn’t advocate for a level of vulnerability where people can be walked all over, however. In fact, she talks about how important it is to set up boundaries, which is actually the most important thing for a positive psychologically safe culture or team. And only when we have boundaries can someone do their best work.

How can we expect people to put value on our work when we don’t value ourselves enough to set and hold uncomfortable boundaries?

You can read more about Rising Strong by Brené Brown at The Story Graph.

Book 10. Right Kind of Wrong - The Science of Failing Well by Amy C. Edmondson

Getting things wrong is a fact of life. One of my most common phrases as a Dad is, “you know what, grown ups don’t get it right all the time, either. And I messed up there. I’m sorry,” but I know that I have high psychological safety with my kids—I’m not going to be fired from the position of “Dad” just because I got something wrong. And you know what, when I mess up, admit to it, and apologise, it’s almost always accepted.

But what about the workforce? We can’t always say, “I’m sorry boss, I got it wrong. Won’t happen again,” and expect it to just be accepted… or can we?

Well, the first thing that Edmonson teaches in her book is that we need to be ok with failure:

If you expect to do everything perfectly to win every contest, you will be disappointed or even distressed when it doesn’t happen. In contract, if you expect to try your best, accepting that you might not achieve everything that you want, you’re likely to have a more balanced and healthy relationship with failure.

And a balanced, healthy relationship with failure is required in both in the workplace and outside of it. You aren’t going to get it right all the time, and that’s fine. But the important thing is to let someone know that you got it wrong. Because what you might see as a small failure might end up being much bigger, if it is not dealt with:

When people don’t speak up about small failures—say, an accounting error—these can spiral into larger failures, such as massive banking losses.

The interesting thing is that, according to Edmonson, there are three types of failure:

• Simple
• Complex
• Intelligent

Simple failures are the simplest mistakes that we make; they are the tasks that we know how to do properly, but we get wrong for some reason. Perhaps you’re baking a cake and, even though you’ve baked hundreds of cakes before and the recipe has always remained unchanged, this time it doesn’t come out right.

Complex failures are similar to simple failures, except that a combination of external factors have conspired in a way which makes the situation completely different to normal. Let’s say that you’re baking the cake, except that this time you’re doing it with an air fryer. Because the air fryer changes the paradigm, you’re likely to get it wrong—as anyone who has used an air fryer for the first time might attest to, regardless of what they were trying to prepare.

But an intelligent failure is when you’re doing something completely new for the first time. You’re more likely to fail because it’s the first time that you’re doing something brand new. Think back to the first time that you ever studied a foreign language or picked up a guitar: did you get things wrong? Sure you did, because it was brand new.

And the important thing about all three kinds of failures is that they are different to errors.

The important thing to remember about errors is that they are unintended—and punishing them as a strategy for preventing failure will backfire. It encourages people not to admit errors, which ironically increases the likelihood of preventable basic failure.

So the important thing is to praise intelligent failure but not to punish errors. Because intelligent failure is where innovation lives, and it’s how we can fail well.

Acknowledging our shortcomings requires and builds wisdom. Wisdom allows us to know when we’ve done as well as we can, and confronting ourselves will always be the hardest part of failing well.

You can read more about Right Kind of Wrong - The Science of Failing Well by Amy C. Edmondson at The Story Graph.

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:

1. The Miracles of The Namiya General Store by Keigo Higashino
2. Truckers by Terry Pratchett
3. A Death in Tokyo Keigo Higashino

Yes, these honourable mentions are all fiction; but it’s important to note that good fiction is a reflection of real life, and can contain lessons which are clearer and more succinct than a 500 page book on the same topic. As an example, here’s what Terry Pratchett says about leadership in Truckers:

The important thing about being a leader is not being right or wrong, but being certain. Otherwise people wouldn’t know what to think.

In “A Death in Tokyo”, which is a novel about how a detective solves a murder (a perfect analogy for both fixing bugs, and working with code written by others), Keigo Higashino writes about how to deal with a seemingly impossible task. And the kicker being that he does it in a single sentence:

When you clear your mind of preconceptions and stereotypes and simply focus on finding the facts, you occasionally unearth things you could never have imagined.

In Closing

For the fourth year in a row, I’ve used the time and budget that RJJ Software have provided to me for my own continual professional development. You can read through the previous years posts here—I’d recommend it too, as there are now 40 individual books on the entire list.

Because of the time and budget that RJJ have provided I’ve been able to focus my learning on different areas which might, initially, seem tangentially related to software development; but on reflection, I’ve been able to take lessons from each of the books listed here and apply them to my day-to-day work in both software development and leadership.

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).