Books you should read
(that aren’t about software)
It’s natural to learn from other software developers: they understand your problems, they’ve discovered appropriate solutions. But skills and knowledge can also be found further afield. Much of what you do when you develop software overlaps with the tasks of other disciplines: you work with others, you write, you design. But they approach their problems from a different direction, finding solutions that may never be discovered by a software engineer. Even though you write software and these authors do not, what they have learned can still help you.
"What Machines Can't Do", by Robert Thomas
Robert Thomas presents a theory, which you can skip, on the relationship between organizational politics and the introduction of new technologies, as well as a series of case studies which you will read with pleasure and sad recognition. Industrial manufacturing and software development share similar values, resulting in similar organizational conflicts. The engineers who design products and those who implement the manufacturing process have a relationship much like that between software developers and ops: too often, the product is “thrown over the wall” and the processes used to run it are seen as unimportant. DevOps is then a political movement. Ops, like manufacturing engineers, feel undervalued because software development overemphasizes the value of the product over the processes used to release and run it. Thomas concludes with a call on engineers to develop an aesthetic of process, a way of valuing and judging processes on their own merits, separate from that of products. For software any particular release of the product is ephemeral: an aesthetic of process is that much more important.
"Universal Methods of Design", by Hanington, Martin
A user interface can be tested quickly or exhaustively. A design can be judged by the numbers or by its emotional impact, from the bird’s eye view high above it or from within the swirl of users below. Kano analysis will tell you what makes a product delightful; a design charette will help you explore a design space quickly. This book will take you on a quick but informative tour of these and many other ways designers have learned to investigate and solve problems, problems not so different from those that face programmers every day.
"Exit, Voice and Loyalty", by Albert Hirschman
Real-world testing is an involuntary and painful experience for all software projects: users breaking your software as they use it. The economist Albert Hirschman points out that these unhappy users have exactly two options: voicing their concerns or exiting, i.e. giving up on your product. Since your users are testing your software for you, listening to their problems increases your chance of fixing the issues they find. And you often want to keep your users from giving up on your product. Your goal then is to reduce the cost of defects in your software by encouraging voice and discouraging exit. This means making bug reporting easy or even unnecessary, distributing fixes quickly, and as the book discusses encouraging user loyalty.
"Global Crisis", by Geoffrey Parker
The English civil war in the 17th century has been attributed to economic change, religious dissent, political centralization, British geopolitics… an almost endless list of causes. Less frequently mentioned is that the 17th century was a time of massive, simultaneous and unprecedented war across the globe, from England to continental Europe, Russia, India, China and on to the civil wars of Japan. Geoffrey Parker points to an underlying cause: the Little Ice Age and resulting catastrophic and repeated crop failures. The global crisis could not be prevented, but a few states managed to mitigate the disaster; most compounded it with destructive warfare. On a much smaller and less catastrophic scale, the problems you face when writing software may not be as local as they seem. Look beyond your task to the project, beyond the project to the organization. When you can, address the global causes, not the local symptoms.
"How Learning Works", by Ambrose, Bridges et al
Learning is never easy, but it is even harder when you are learning on your own. When in school you have teachers to rely on, when you are new to the profession you have experienced programmers to guide you. But eventually you reach a point where you have to learn on your own, without help or support. You must then know how to teach yourself, which is to say you must first learn how to teach. To acquire such a skill you would need an expert on human learning, and one who is also an able teacher. And if such a teacher were not available the next best thing would be a book that they wrote, a book summarizing what they know and how you can apply it.
</span>