Three books every software developer should read in 2019

By: on June 14, 2019

Ok, that title is tongue-in-cheek clickbait, but here are three books which in my opinion are likely to broaden your horizon by offering surprising perspectives on the most powerful tool that you have at your disposal: your mind (and your body).

I have found these books to be filled with interesting observations and pieces of advice that are applicable in a much broader context than their titles would suggest. In some cases, what I read struck me as directly relevant to (or resonating at some funky meta-level with) my life as a software developer. For each book, I will give a highly incomplete summary of its contents and how it may relate to software development in my own personal view. I present this list in the hope of piquing your interest without spoiling your reading experience (should you choose to read any of the books).

Here goes:

“The Inner Game of Tennis” by Timothy Gallwey

The inner game refers to the mental aspect of tennis or indeed almost all activities in life. The author describes how most tennis players are in a constant dialogue with themselves where part of their mind, “self 1”, gives instructions to “self 2”, the (subconscious) part of their mind that is actually in control of their movements. Self 1 is often engaged in a highly judgemental running commentary of the ‘poor’ performance of self 2. This usually has the effect of making the player tense up and perform even worse. This vicious cycle can be broken. Self 1 isn’t well suited to controlling a player’s body movements, so it needs to sit back, relax, and learn to trust the innate abilities of self 2. This can be achieved by focussing self 1 and tasking it with observing self 2’s actions (and resulting outcomes) in a nonjudgemental way, i.e. it’s proper job is to simply see what is. If, let’s say, you’ve hit the net again, don’t beat yourself up about it. Visualize the desired outcome (i.e. not hitting the net) and then let self 2 do it without interference from self 1. Engage in a loop of first visualizing the target outcome, then letting self 2 act and finally observing the actual outcome. This sets you on a path of convergence.

This loop can be applied to the process of writing a software system from scratch. You might not know from the start what shape the final solution actually needs
and thus might be a bit nervous. Still your mind and trust in your abilities to converge on a good solution. Don’t beat yourself up about setbacks on the way.

Furthermore, I think that trying to see what actually is is a fantastically useful skill: Have you ever realized after hours of trying to find a bug, that the problem was staring you in the face all along, but that you saw only what you wanted to see?

“Extraordinary Swimming for Every Body” by Terry Laughlin

A wide-spread, obvious theory of swimming is that you go forward by pushing water backwards with your hands. There is a better way: ‘anchor’ your hands and propel your body past them through hip/core rotation while keeping your muscles connected. The first way of swimming focusses on your arms, which tire easily. The alternative way focusses on your core, which doesn’t. Mindlessly trying to optimize the wrong thing will grind you down.

Translated into the world of software development, this obviously states that imperative programming with mutable state (and in my book, that includes you, OOP) is like pushing water with your hands, while functional programming is a smarter, less tiresome way of moving. (Then again, a function that closes over an environment is quite similar to an object with a single method. Think about it.) Keeping your muscles connected clearly means don’t npm install all the things, but instead pursue an understanding of what you are doing (the long-term payoffs will be great). The good news is that you can change your ways (/paradigm) and an old dog can absolutely learn new tricks.

“Meditations on Violence” by Rory Miller

Covers a lot of ground and is brimming with insights. Among many other things, the book highlights the value of building up and trusting your own experience over theories (here: Martial arts) that, though presented with great conviction, might not actually work (perfectly / well / at all) in practice (your particular situation). You cannot block every punch and you cannot expect an attacker to play by your rules; thus, getting hit is inevitable and learning to cope with it is important.

Regarding software development: It’s unlikely that you will get everything right on a project and that everybody always follows the same rules nicely. Reality is messy, pressure will be put on you, you will make mistakes and unforseen external factors will push you off balance. However, this doesn’t necessarily spell defeat. Don’t give up! (Well, at least don’t give up easily.)

Conclusion

I hope you got some enjoyment out of my list—of course, you might see other analogies and/or draw completely different conclusions!

For example, for Meditations on Violence, my colleague Tim Band suggested the following analogue for software development: The only reasonable experience for dealing with problems in production comes from being involved with dealing with problems in production. There isn’t a training programme that will prepare you for this; any kind of practice you might do beforehand is different from the real thing and the next problem might be totally unlike the last one.

Share

Leave a Reply

Your e-mail address will not be published.

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*