40 Books; One Year... so far

I've consumed 40 books so far this year. And that's alongside countless podcast episodes, too — at the time of writing this post, I'm subscribed to 70 podcasts.

I have a separate post containing quotes from podcasts, which will be coming soon

Friends have asked me how I consume this much content, essentially, I travel a lot and prefer to read a book/ebook rather than stare out the window, or doom-scroll while sitting on a train.

I'm in the process of writing a blog post about the books and podcasts that I've consumed this year, and it'll be out shortly after the festive season. But I thought that I'd share some key insights from this year so far.

These quotes are important to any line of work, but one or two are specific to software development — even though they can be applied to any walk of life.

The Art of Living

Every single day presents new challenges, and those challenges often require us to learn something new about or refine our thinking on the tasks at hand. I take "the truth" here to be the truth of the matter behind the task - the "why" as it were.

This is particularly important in software development, as we often have to pivot when we are presented with new information about a problem that we're solving. But it also affects all other industries, too.

In my own experience, I've abandoned my current view of a problem whenever I'm demoing a piece of functionality to a client. I'll often show off the functionality, what it does, how it works, and why I've built it; but then immediately follow up with two questions:

1. Does this match how you thought it would work?
2. What could be improved to make your users happier when using it?

This is because I have a preconceived notion of how people will interact with the software, based on my own experience of building the software. But I'm too close to it to make a meaningful call on whether the design is right for the problem it's going to solve. The only people who can answer that are the users.

But this doesn't just apply to development work. I often ask myself to abandon my current view whenever one of my kids is upset. I might know why they're upset, but I might not know the nuance of the context which has led to them being upset. So I abandon my current view, and listen; I wait until they have finished explaining, and wait a beat longer. Then the real reason for the upset comes out. Only then can I figure out a way to fix the situation or heal the wounds.

Facts, Facts, Facts!

We need to try to see the problems ahead of us as objectively as possible. By stepping back and focusing on what you know and what you have been told, rather than what you assume, presume, or are inferring, you can see the problem or task for what it is. This allows you to provide an elegant solution to the problem, and nothing more — we'll see why that's important in a moment.

It's often the case, that we misunderstand or misinterpret the minutiae of what someone wants us to do. This is usually because we have our own understanding, experiences, and context which we use to help us solve a problem or complete a task. Usually relying on past experience and understanding is fantastic, but sometimes this can cause us to make a few inferences which don't make sense in the current context.

We also have to try to focus on being as clear as possible when providing instructions or when gathering information on a task. One of my favourite ways to explain this visually is the "peanut butter and jelly sandwich" challenge. Here's an embedded version of that video:

This video perfectly demonstrates how we make assumptions when giving out instructions to others. It also shows what happens when we blindly follow the exact instructions - but in a very silly way.

Simplest is Always The Best

Regardless of the problem you are solving, always go with the simplest solution. A common acronym in software development is: KISS, which means "Keep It Simple, Stupid." By focusing on the simple solution, you'll make it easier for everyone to understand and implement. Simplest is always best.

In my own experience, applying the KISS principle helps to not only build solutions which are simple to use but also simple to maintain. Businesses evolve constantly, and their processes and systems need to evolve with them. By building something incredibly complex, all you're ensuring is that the only person who can maintain it is you. You might think that this is great for job security, but what happens if you get hit by a car or are taken ill?

Another important principle in engineering is the Bus Factor. It's rather grizzly, but it asks the question: how many team members would have to be incapacitated before you have to abandon the project? The higher the bus factor, the safer your project is. And if you have a super complex solution, that only a handful of people (or perhaps just one person) understand, you're looking at a very low bus factor.

I always think: if a junior read through this solution, would they be able to understand it? This is because I always have this (mis)quote from Steve McConnel's Code Complete in my head when creating any solution:

Our main directive as software developers is to write code for other developers to read; not for the compiler to read

The tools we use as developers are getting more and more complex, and are able to make our code more efficient in ways that we could likely never imagine. So let the tools do their job, and let's focus on the human side of our work.

Specific vs Generic

Only when you need a generic solution should you create one. You only have an understanding of the problem you are solving, not the generic case. Eventually, when you understand the generic case, you can make the solution generic. Until then, keep it simple and focus on the problem you're solving.

There is no point in solving a problem that you don't understand, yet there are developers out there who will try to create a solution to a generic problem rather than the specific problem at hand. I always focus on the specific problem at hand, because I have a clearer understanding of that problem versus a generic one.

Let's say that I'm tasked with creating a trashcan which has a levered lid. I can step on a peddle at the base of the trashcan which will open the trashcan, allowing me to place something in there without having to use my hands to move the lid. I could work on a version of the trashcan which uses an innovative design — maybe someone out there has disrupted the trashcan lid market and created a smart trashcan that you can open with your phone; an IoT trashcan — but I have a specific brief: user steps on peddle, trashcan opens. My solution should be tailored to the specific instructions, because if I start thinking about, "how can I add IoT to this device?" I'll start adding complexity which isn't needed. Especially since the client might not be interested the IoT market.

Solve the specific problem.

In Conclusion

Reflecting on the insights gained from 40 books and countless podcast episodes this year, I've found that each piece of wisdom forms a mosaic, contributing to the evolving picture of my understanding. In the words of Thích Nh?t H?nh, we're all on a path, progressing and refining our perspectives. This journey involves a readiness to abandon preconceptions, allowing room for deeper truths.

Keigo Higashino's notion of clearing the mind of stereotypes resonates deeply. Objectivity, devoid of assumptions, unveils hidden dimensions in challenges. It's a reminder to focus on what's known and told, not what's inferred, simplifying the problem-solving process.

The golden rule from Chris Zimmerman, advocating for simplicity, reverberates across disciplines. Whether in software development or life's complexities, simplicity proves consistently effective. "Keep It Simple, Stupid" becomes a guiding principle, streamlining understanding and implementation.

Lastly, Zimmerman's advice to solve the problem at hand before tackling broader issues is a valuable lesson. By understanding the specific, we pave the way for effective, nuanced solutions.

As I navigate the remaining chapters of this year, I carry these insights as beacons, illuminating the path toward continuous growth and understanding. Here's to the many more lessons yet to unfold in the pages and podcasts of the coming months. May they enrich our perspectives and contribute to the ongoing journey of knowledge.

Make sure to connect with or follow me for a more complete post about the top ten books that I have read this year. You can also find my posts for the last three years (that's 30 books for you to read, and why you should read them) here.