You take away something from almost every book you read. But every once in a while you stumble across a book right when you needed the nudge — and the impact of such books is disproportionately large. You are wrestling with a problem and feeling at your wit’s end and then voilà! — the solution presents itself, ready to be applied. Not a hack or one-time trick that you picked up, but something that deeply changes the way you think and work.
This post is about such books that really helped me professionally in a very profound manner — because I happened to discover them at the precisely right time. As such, it is a personal post (and a nostalgic one) — so, caveat lector.
Design Patterns by the GoF
“One thing expert designers know not to do is solve every problem from first principles.” — Introduction, “Design Patterns” by GoF
In the early 2000s, after a couple of years of working as a software engineer, I was working on a rather complex desktop app — a WYSIWYG design editor for textiles. You could apply a dozen different operations on virtual cloth — warp & weft patterns, textures, layers, colors, etc. And then came the requirement to support to “undo and redo” these operations. I did an embarrassingly terrible job with a lot of band-aid code. Moreover, every time there was a new operation added, I had to rejig the whole thing! The result was a fragile system where more time was spent fixing old things than building new ones.
There was no StackOverflow back then, not even enough published tech blogs that we could find a readymade fix. Then, a friend introduced me to the “Design Patterns” book and I was hooked. I quickly found the right way of handling undo & redo (using Command and Memento patterns). But the book instilled in me a life-long reverence for several things:
- Patterns: I started seeing them everywhere. I still try and read every book on patterns I can find. I even got a chance to be a co-author for a book on patterns (Design Patterns in Symbian OS — 2008, Wiley). Currently reading Christopher Alexander’s “A Pattern Language” — which is the OG book on patterns in Architecture.
- Articulating the problem first: This was my biggest takeaway from the book. Instead of sketching out the solution, the book spends far more time describing the categories of problems where the solution can be applied. The format used to describe each Pattern is an excellent way to explain any given solution (Intent-Motivation-Applicability-Structure-Consequences-Implementation-Code-Related Patterns).
- Common Vocabulary: Soon after I discovered this book, I realized the importance of using a common vocabulary to convey ideas in a loss-less manner. It is far more elegant to say “we will need an Adapter to connect to that payment gateway” than use paragraphs with arbitrary tech jargon thrown in.
- Don’t reinvent the wheel: The authors didn’t invent any of the patterns mentioned in the book. The book was a result of an extensive survey where the authors compiled a list of commonly-used solutions for a set of recurring problems. It is important to look for existing solutions, including their consequences, before trying to create your own solution.
Code Complete by Steve McConnell
“Copy and paste is a design error”
Like it is with many others, getting my code to run was a big enough challenge for me in my early years as a programmer. There was so much to learn about the basics of programming, operating systems’ quirks, build options, UI tricks, etc. I was so busy learning the tools, I didn’t really spend any time learning the craft. It wasn’t expected of me either.
I was lucky to have a fairly well-stocked library at the office, which had everything from “Numerical Recipes in C” to “Design of the Unix Operating System” to the latest book on .Net (back then a very new and much-hyped thing from Microsoft). In a corner were the rarely-read books (you could tell by the amount of dust collected on their covers) — all thick books with intimidating titles. “Code Complete” was one of them. The title intrigued me and the subtitle — “A practical handbook of software construction” — even more so. So I conquered my fears and flipped through the book one evening and I was hooked from the introduction. It never left my table after that.
“Code Complete” was my first book-as-a-mentor at work, helping me understand software craftmanship that I didn’t know existed. It zoomed in and out, talking about coding best practices, architecture, estimations, common pitfalls, refactoring, code organization, performance, software quality, self-documenting code, conquering complexity, and a thousand other things. It primed me to appreciate the great books on software craftmanship that followed — Martin Fowler series of books, Domain-Driven Design, Clean Code series by Robert C. Martin, etc. There were little sidebars that talked about some useful techniques, hard data, and (most famously) common errors programmers make called “Coding Horror”. “Coding Horror” still lives on with Jeff Atwood’s (very readable) blog and his Twitter handle (Atwood is the co-founder & CTO of StackOverflow and later Discourse).
It was a rather influential book for software professionals back in the day and I am glad I read it when I did. I think this is the book that I most frequently gifted to my colleagues at work. Sadly, not everyone found it as illuminating and I must admit that it is quite dated now.
Applied Cryptography by Bruce Schneier
“Security is a process, not a product.”
If you are dabbling with software, you will have to deal with cryptography sooner or later. And the same happened to me as well. For a particular feature, we had to encrypt messages using Public-Key Cryptography. I was able to get around using journals, code samples, how-to guides, etc. and I thought I did a good job. Soon after, my boss asked me to give a seminar on Public-Key Cryptography — that’s when I realized how little I know about the topic! I had studied a bit about it in college but that was hardly enough to claim I know anything.
I rushed to the bookstore and purchased a few books, including 2 textbooks, and sampled them frantically over the weekend. Most of them were too dense and hard to read. Schneier’s book was also full of jargon, flowcharts, pseudo-code, but he made it easier for the reader. It started with Steganography, simple ciphers, the need for encryption, and had Alice, Bob, and other dramatis personae playing out various security scenarios (scenarios featuring Eve, the eavesdropper, were invariably the most interesting). The maths and the detailed algorithms came much later in the book after the key (no pun intended) concepts were explained. This taught me about concepts like PKI, Zero-Knowledge Proofs, session keys, one-way hash functions, digital signatures, and so on.
At that point, I didn’t quite know the legendary status of Schneier but since then I have tried my best to read everything he has published. I still subscribe to his excellent “Cryptogram” newsletter (18 years and counting!). In particular, his annual “movie-plot threat” contest (2006-2015) entries are still fabulously scary to read. I had even tried to play around with his “Solitaire” (aka “Pontifex”) cipher — something Schneier devised specifically for Neal Stephenson’s genre-defying “Cryptonomicon”.
On the topic of cryptography, I must also mention Simon Singh’s “The Code Book”, which is an excellent account of the evolution of cryptography, from the rudimentary substitution ciphers to quantum cryptography. I read it alongside “Applied Cryptography” and absolutely loved it.
These two books not just ignited my interest in cryptography, which served me well in understanding everything from eCommerce to blockchain, but they also made me appreciate the importance of data security, user privacy, and other higher-level concepts long before they became mainstream.
Getting Things Done by David Allen
“Anything that causes you to overreact or underreact can control you, and often does.”
By 2007–8, I was leading small teams and was getting absolutely overwhelmed by the sheer number of things I had to do just to keep my head above water. Switching contexts was absolutely killing all my productivity. I had read about concepts like Csikszentmihalyi’s “Flow” but just could not find any reliable technique to manage my time. Then I discovered “Getting Things Done” (GTD) in the office library and the subtitle “The art of stress-free productivity” absolutely sucked me in.
I remember reading it and realizing very quickly that it isn’t like a self-help book, it demands the reader to act, not just ruminate on the ideas! GTD was an involved, precise framework for organizing your work that claimed that “open loops” — things that are on our minds but we haven’t acted upon — are the primary reasons of stress . It encouraged externalizing our tasks and reminders to a “trusted system”. It talked about the challenges of knowledge work and that we cannot really manage “time”, we can only manage tasks and projects. The edition of the book that I read was still rooted in the world of (physical) folders, inboxes & outboxes, notebooks, and so on but the underlying concepts translated excellently to my world of email, MS Word docs, and personal wikis. (I believe the newer edition is more software friendly but I haven’t read it yet.)
I didn’t ever follow GTD religiously but I found the act of collecting, processing, organizing, and reviewing very, very useful over these years. Reading it when I did really helped me get a grip on how to deal with unfinished things, understand the limitations of my own memory, define a “trusted external system”, and come to terms with the fact that I am terrible at multi-tasking. There is no way to objectively quantify this, but I think I would have suffered a lot professionally (even personally) without learning about GTD!
The Four Steps to Epiphany by Steve G. Blank
“‘Build and they will come’ is not a strategy, it is a prayer!”
After around 15 years of working in software, I found myself in charge of defining the product strategy for a healthcare product at a tiny startup. I had a fair amount of hubris, having a not-unsuccessful track record, and thought I could just reapply what I know in order to succeed in this entirely new ballgame. In a couple of months, I wasn’t fooling even myself with that viewpoint😅
I had a brush with a startup environment earlier although I was mostly cheering from the sidelines then. I had been through the product-market fit cycle (not very successfully) and found that I lacked many basic skills. Like most other first-time-startup folks, I had devoured Eric Ries’ “The Lean Startup” — but somehow it didn’t stick with me. While following the breadcrumb trail from the book, I stumbled across Steve Blank’s work (Blank was an investor in Ries’ startup and later collaborator on the Lean Startup workshops). It was hard to find a copy of “Four Steps to Epiphany” but when I finally read it, it changed everything I thought I knew about startups and entrepreneurship.
In many ways, this book is an anomaly here on this list. Unlike the rest of the books here, I found this one incredibly hard to read and harder to apply. I finished the other books in one or two sittings but I was practically scared to read this one! With every page Blank challenges you to rethink your approach, to do things that you are not very comfortable with, to do things that won’t scale initially. Many of these ideas flew in the face of what I knew and loved, but almost everything in Blank’s “Customer Development Process” made sense. Blank’s book doesn’t dispense sterilized, prescriptive advice, nor is it a glorified biographical record of a successful company. Instead, it is a treasure trove of brutal advice to first-time entrepreneurs on what usually goes wrong and how they can minimize the damage. Almost every page lays out a bunch of actionable questions — “How will you do X? How will you find the right contacts? How many calls have you made? If you succeed with A, it would lead to B — how do you plan to deal with B?”
“In a startup no facts exist inside the building, only opinions.”
I never managed to finish the book from cover to cover — it was too dense and intimidating for me. But reading it when I did helped really change the way I look at entrepreneurship. I revisit the Customer Development Process at least once a year and every time it helps me understand a new nuance that I had overlooked. I feel everyone who wants to build a product, should read this book (or its more readable successor “The Startup Owner’s Manual”).
The Hard Thing About Hard Things by Ben Horowitz
Marc [Andreessen]: “Do you know the best thing about startups?”
Ben [Horowitz]: “What?”
Marc: “You only ever experience two emotions: euphoria and terror. And I find that lack of sleep enhances them both.”
In general, I usually find most memoirs too embellished, lionizing an iconic leader or a company, focusing disproportionately on what went right as compared to what went wrong. I didn’t have high expectations with Horowitz’s book either. The first few pages were ho-hum and, since I am not all that much into hip-hop, I was more confused than entranced by the hip-hop song snippets at the beginning of each chapter. These first few pages were throwbacks to the author’s early days as a student, which I dismissed as the usual ploy to “humanize” the author. But then, Horowitz jumps into his Netscape days — and he doesn’t talk about how awesome it was. Instead, he narrates some of the horror stories — the constant pressure from the large corporations, the possibility that the Web would be a proprietary playground, the sudden fall of Netscape, and so on. From here onwards, the book blew my socks off.
Horowitz pulls no punches in the book, calling out many mistakes that happened along the way. This isn’t a story about how a bright idea, the heroics of a brilliant engineer, or the relentless hustle of the founding team helped shape a product or a company. There are many tragicomic instances of Murphy’s Law recounted throughout the book — showcasing the unsexy, unvarnished, blood-sweat-tears reality of running a company that is rarely written about, forget upvoted enough to enter into our filter bubbles. There is a brutal honesty in Horowitz’s writing which makes this a compelling read. The book has a lot of good wisdom on hiring, managing teams, failing fast, growth pangs, balancing personal and professional lives, and finding the courage to lead during hard times — lessons learned the hard way and not presented as prescriptive, superficial advice that’s all too common these days.
“The hard thing isn’t dreaming big. The hard thing is waking up in the middle of the night in a cold sweat when the dream turns into a nightmare.”
Anyone who is enamored by the glitzy promise of a startup and wants to start or join one should read this before jumping in with both feet. This book helped me immensely to understand my limitations and make peace with the chaos and uncertainty of a startup without losing my mind.
Deep Work by Cal Newport
“In the absence of clear indicators of what it means to be productive and valuable in their jobs, many knowledge workers turn back toward an industrial indicator of productivity: doing lots of stuff in a visible manner.”
If David Allen’s “Getting Things Done” got me interested in purposefully managing my tasks and projects and respecting the calendar, “Deep Work” really helped to identify what is my definition of personal productivity. Productivity is incredibly hard to quantify in knowledge work and, by default, we tend to go with the poorly defined, one-size-fits-all measures employed by our bosses or companies. This obsession with untrue metrics of productivity, because they are easier to measure, has been a constant source of annoyance for me. This book asks the reader: “Forget about others, what do you consider as a good measure of your productivity? And how do you maximize it?”.
Deep Work, of course, is in contrast with “shallow work” that we all tend to do — reacting to what comes in, instead of charting a path to maximize high-quality work that defines us as professionals. Such high-quality output, by its very nature, needs intense focus and uninterrupted periods of concentration — which is very rare in fast-paced, “we-wanted-it-yesterday” kind of work environments. Newport proposes a variety of ways to allow yourself to perform deep work: some practical and some kind of out there. Whatever you make of the tips and techniques, what I was sold on was the compelling case the book builds for deep work. Newport argues that “distraction-free concentration pushes our cognitive capabilities to the limit”, which in turn creates new value, helps us improve our skillset, and helps us create our own brand as professionals. For me, this evoked parallels with the spirit of professionalism — “Shokunin” (職人) — which is rarely seen now.
Newport, a CS professor with a Ph.D. from MIT, is no idle commentator. He works on pretty complex distributed systems theory. Before this one, he had already published many books to help students do better and had a successful blog since 2007. He knows a thing or two about deep work. His advice ranges from some techniques on how to manage your time better to quitting social media altogether, from “monastic” seclusion to a “rhythmic” on-and-off deep work routine. “Deep Work” became his rallying call to stop glorifying the “epidemic of busy-ness” that seemed to have taken over most of the knowledge work industries today.
I found this book to have little re-read value though. It feels like a drag to revisit the ideas again. The book could have been leaner, less repetitive, with fewer examples and anecdotes. Thankfully, reading this book when I did, helped me distinguish between being busy and being productive. The idea is not to reject any shallow work (it’s not in our hands) but to consciously make time for deep work. To me, it worked better as a book about developing one’s craft by making time as opposed to a list of time management hacks.
Of course, there are dozens of other books I had to exclude from this list. But I do hope that I keep discovering books serendipitously at the exact right time.
