If you are old enough to remember book stores, you would walk past the computer book shelf (or if you were lucky, shelves, or the extremely fortunate would find an entire section of the book store dedicated to computers and technology).
Now, those books aren’t quite as accessible. It is harder to wander down the aisle and thumb through a book to see if its worth while. While there are online bookstores and temporary loans, that just doesn’t have the same accessibility of “open to a random page and see if it looks useful.”
Thus, people often ask the classic question of “what do you recommend reading?” I’m also going to preface this with - I’m trying to stay away from the classic classics. They are wonderful books, and others may indeed recommend them for their value (and I’ll admit to slipping one of them on here). I’m trying to name the books that you will not necessarily have seen on the end-caps in the computer section of the book store. I’m admitting to wanting to be that guy who came up with the eclectic mix tape that made you think a bit more than the classic rock mix tape (that really rocks).
The first thing that will come to mind when seeing that title is “ug, another book on patterns.” Or maybe “I thought it was named Design Patterns - Elements of Reusable Object-Oriented Software”
This isn’t anything like that book. Or maybe it should be. The full title of the book is A Pattern Language: Towns, Buildings, Construction. Yes, this is a book about architecture - but not software architecture. It is about the houses and buildings that we walk live and work in.
The description of A Pattern Language is one that will sound very familiar to people familiar with Design Patterns:
It is shown [in The Timeless Way of Building], that towns and buildings will not become alive, unless they are made by all the people in society, and unless these people share a common pattern language, within which to make these buildings, and unless this common pattern language is alive itself.
In this book we present one possible pattern language, of the kind called for in The Timeless Way. This language is extremely practical. It is a language that we have distilled from our own building and planning efforts over the last eight years. You can use it to work with your neighbors, to improve your town and neighborhood. You can use it to design a house for yourself, with your family; or to work with other people to design an office or a workshop or a public building like a school. And you can use it to guide you in the actual process of construction.
The elements of this language are entities called patterns. Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice.
This is the book that inspired Gamma, Helm, Johnson and Vissides.
By reading A Pattern Language you will be able to understand what the authors of Design Patterns were trying to do and how design patterns were intended to work.
It’s a good book too, who knows what else you will find useful in it. Pattern #146 describes a flexible office space. Pattern #148 describes a workspace for small work groups, #151 is about small meeting rooms, #152 is a half private office. Everyone who works in today’s world of computers and cubes, can use these ideas to conceptualize and consider improvements to the office.
There are several things in this book that it has going for it. The essay “Cracking the Oyster” starts out with a simple question: “How do I sort a disk file?”. This question turns out to be probably the earliest documented XY problem and the essay works through the actual problem that is being sought. (A reading of this one and seeing someone else go through the process of trying to figure out the problem should be required text for people who keep getting their questions closed as ‘unclear’ on Stack Overflow and Exchange).
The pearls of wisdom that this book provides - are in easy to digest short chapters (its original form was that of a column in Communications of the ACM). Each chapter stands on its own, as something that you can read quickly, and take away something new from each time you read it.
Many of the problems, puzzles, and the solution to these puzzles are ones that interviewers will ask. Even looking at the process of how to solve the problems interviewers don’t ask, can be invaluable.
I’ve often quoted How to be a Programmer. I first found it hosted at samizdat.mines.edu (now offline, though one can still find it through archive.org), though it has now found its way to GitHub with some updates since then.
I believe it to be an invaluable resource for readers of all skill levels. From the fundamentals of Learn to Debug to to the point where you are a senior developer and looking at How to Get a Promotion or How to Develop Talent. It is a text that has something for everyone.
This is the hard copy of it (or if you go for the Kindle version, the softer copy). It is essentially the same as the version online - just something that is easier to carry about (don’t get me wrong, the github markdown version is wonderful - just that its a tad bit more difficult to log into your server and view the markdown at night than it is to pull out a kindle app on some device.
It is a good essay or book however you find it. Just a matter of formatting. And whatever the format, read it.
The world of programming isn’t only about code. The previous book review touched on that. The other half of the job is working with people. Be it as a solo free-lancer, or a cog in a giant business - you will work with other people. And more than a few of those people are going to demand things now.
Even if you find yourself with the most laid back boss, you will need to communicate with him or her. You will need to promise what you can deliver and deliver what you promise. Both failing to meet or exceeding those commitments are possible issues.
This is a book about communication. It is about making sure that we are properly commutating with people about what we are doing, when we are doing it, and what it will take to do it. Not everyone we work with will be a fellow programmer who we can drop into the deepest inscrutable jargon with. We need to make sure we communicate and avoid possible conflicts that arise from that communication - and when those conflicts do occur, figure out how to resolve them.
The full title is Slack: Getting Past Burnout, Busywork and the Myth of Total Efficiency. Quite a mouthful. It is written by Tom DeMarco of Peopleware fame.
Today’s world is everyone running the Red Queen’s race.
“Well, in our country,” said Alice, still panting a little, “you’d generally get to somewhere else - if you run very fast for a long time, as we’ve been doing.”
“A slow sort of country!” said the Queen. “Now, here, you see, it takes all the running you can do, to keep in the same place. If you want to get somewhere else, you must run at least twice as fast as that!”
And the thing is, it is only by slowing down that we can move forward.
By having some slack in the schedule, we are able to respond to the emergency in a timely manner and manage those risks. It is that slack hat allows the business to change as situations need. Slack helps reduce workplace stress and the feeling that when you are ‘behind’ you need to go faster to catch up (which results in more errors). The slack is the opportunity to learn and grow.
This doesn’t mean slack off, but rather that having slack allows people to take up other tasks and situations as the organization needs it. It allows the organization to take risks and grow rather than spending all of its time trying to become ‘efficient’ while losing the ability to be ‘effective’.
Handing this book to your boss may or may not be a career limiting move. DeMarco is rather critical of bad management and inflexible organizations. The ideas presented are heretical in some organizations. And yet, it is one of those books that plants seeds of ideas that have the possibility for making a better working environment.