TL;DR
Every now and then, a “shortcut” to learning shows up and promises to save us time, money, and maybe even a bit of guilt about the unread books piling up on our shelves. Yup, guilty as charged. 🙈
You've probably come across the services or apps that condense an entire book into a handful of bullet points, a 10-minute read, or a quick audio recap. On paper, it sounds brilliant. Read more, faster. Learn the key ideas. Skip the fluff. Done.
But is it actually useful?
My take is that summaries can be helpful, but only in a very specific role: as a filter, not as a replacement. In a podcast episode I recorded with my friend Shawn, he comes at it from a slightly different angle and makes a strong case that many books are bloated anyway, so maybe stripping them down is not such a crime after all. 🤷♂️
As usual, the truth is somewhere in the messy middle.
If you prefer audio content, you can listen to the full episode here, and below I'll provide a TL;DR (yeah, summarries of summaries of summaries 😅)
The appeal of book summaries
I’ll admit it: I was intrigued by the idea.
I tried Blinkist for a while because, like many people, I love reading but I’m not exactly the fastest reader on the planet (even though I completed the speed reading courses, read books on the topic, etc.). The idea of being able to “consume” more books in less time felt like a superpower. Read the essentials, move on, repeat. Nice and efficient 💪
But after using it, I started feeling that something was off.
Sure, I could get through the summary. Sure, I could tell you the supposed main points. But very often I was left with this weird feeling of: “Okay... and?”
It felt like I had skimmed the skeleton of an idea without really absorbing it.
That, to me, is the core weakness of summaries. They can tell you what a book is about, but they often fail to give you the experience of thinking through the book.
And that part, for me, matters more than anything.
A summary can help you choose the right book
That said, I don’t think book summaries are useless.
Quite the opposite.
I think they’re actually pretty good as a decision-making tool.
Sometimes a book has a great title, a compelling cover, and glowing reviews, but you still don’t know whether it’s worth your time. In that case, reading a short summary can be a practical way to test the waters before committing several hours to the full thing.
A summary can help answer a simple question: “Do I want to invest my time in this book?”
And that’s a perfectly valid use case.
Because let’s be honest: reading every interesting-sounding book cover to cover just isn’t viable.
The real value of longer books
Where things got interesting in the episode is when we started talking about repetition.
Shawn’s point was that many books could probably be much shorter. You’ve probably seen those reviews on Amazon too: “This should’ve been a 50-page book, but they stretched it to 300.” And honestly, he’s not wrong. Plenty of books are padded.
But I argued that with good books, repetition is not always a waste of paper.
Sometimes repetition is actually reinforcement.
Or maybe, more accurately, it’s not repetition itself that matters; it’s the repeated explanation through different examples, angles, and stories.
That’s a subtle but important difference.
For example, I mentioned As a Man Thinketh, which is a very short book. So short, in fact, that if you read it early in your personal development journey, you might think, “That’s it? This is what all the fuss is about?”
But later, after reading other books that explore similar ideas in greater depth, you come back to it and suddenly realize there’s more packed into those few pages than you first noticed.
In other words:
- Some short books are dense and powerful.
- Some long books are bloated.
- And some long books earn their length by helping ideas actually stick.
Examples beat bullet points
At one point, we also touched on something I’ve noticed about how I learn best: I tend to remember examples much more than abstract lists.
Take a book like The DevOps Handbook. What stays with me is not just a checklist of principles. What stays with me are the case studies. The stories. The examples of what companies actually did, what changed, and why it mattered.
That’s why summaries can feel incomplete.
A summary may give you the “what,” but often it strips away the “why this matters” and the “how this plays out in real life.”
And that’s usually where the real learning happens.
It’s one thing to read:
do steps one, two, three, four, five
It’s another thing entirely to see how those ideas played out in practice, where they worked, where they didn’t, and what tradeoffs were involved.
That extra context is often the difference between recognizing an idea and actually understanding it.
What about technical books?
Since this is DevThink, Shawn asked the obvious question: does any of this apply to technical books?
And here I think the answer is pretty straightforward: Not really.
Or at least, not in the same way.
You probably can’t learn a programming language, architecture style, or engineering discipline from a stripped-down summary. Technical books usually depend on buildup, examples, code, explanation, and progression. Remove too much, and the whole thing collapses.
A summary might still help you decide whether a technical book seems relevant, but it’s not going to replace actually working through the material.
You can’t compress genuine hands-on understanding into 10 bullet points and call it a day. Well, you can, but your future self debugging production at 2 AM may have some opinions about that.
So, are book summaries worth it?
My conclusion is pretty simple:
Yes, but only if you use them for the right job.
Use summaries to:
- preview a book
- decide whether it’s worth your time
- refresh your memory after reading the full book
Don’t use summaries to:
- replace deep reading entirely
- assume you’ve “read the book”
- expect real understanding from a compressed list of takeaways alone
A good book often does more than just deliver information. It helps you sit with an idea, revisit it, see it from multiple angles, and connect it to your own experience. That part is hard to summarize.
So no, I don’t think book summaries are a magic shortcut.
But as a smart filtering tool? Absolutely.
Full Transcript
Episode: DevThink Podcast – Book Summaries
Audio: Listen here
Shawn: Hey, everybody. Welcome back to the DevThink podcast with your usual hosts, Shawn and Nikola. Today’s fun topic is a relatively new phenomenon, at least to me: downloadable book summaries, whether as audiobooks or ebooks. These are much shorter versions of books where someone else has read the full thing, extracted the major points, and packaged them up so you can either be lazy or decide whether you want to buy the actual book. What do you think, Nikola? You’ve had more experience with these than I have.
Nikola: Yes. I actually tried a service called Blinkist. Honestly, at first, I liked it. I liked the idea behind it. You think, “Oh, awesome.” I mean, I like to read a lot. But then again, I’m not exactly a fast reader, and I really want to get through all these books. Then, as I started using it, I realized I wasn’t getting much value out of it. You read a summary and then you’re like, “Okay, wait, so I read these 10 bullet points... now what?”
Although, to be fair — and honestly, this will probably be our shortest episode ever — I do think book summaries are useful when you’re trying to decide whether or not you actually want to read the full book. Here’s the thing: if a book is good, it tends to repeat its main premise, idea, or conclusion multiple times. What I mean is, if you read the whole book, it will stay with you longer than if you just read the summary. So that’s where I stand.
What do you think, Shawn?
Shawn: That’s interesting. I only read one for the first time recently, and I mostly saw it as something I would use not instead of reading the book, but to decide whether I wanted to read the book. There’s the old phrase, “Don’t judge a book by its cover,” and if you can’t judge a book by its cover, how can you judge it other than by reading it? But reading every book would take however many hours per book, and that’s just not practical. So I think it’s a good idea if you want to decide whether to get the book.
On the other hand, when you mentioned repetition, I immediately thought, “Yeah,” but then you said that was a good thing, and I was like, “Whoa, we’re completely opposite there.” Because for you, repetition helps you learn it throughout the course of the book. But from my perspective, a lot of books — and I’ve read a lot of reviews on Amazon — are described as books that should have been 50 pages, but got padded out to 300 because no one’s going to publish or buy a 50-page book. Every book has to be 300 or 400 pages to get sold.
So I’m thinking, if you can take out all the repetition and it becomes something I can read in under an hour, maybe that’s a good thing.
But my last thought is: what does this have to do with DevThink and developing? Is this even something you can do with a technical book? I’m going to go out on a limb and say you couldn’t do this with, say, a programming language book. You can’t teach someone a programming language by stripping out 80% of the book. So is this good for technical books? Is this something our audience can use, or are we just passing along general public-service information about pop psychology, self-help, sociology, and that sort of thing?
Nikola: Yeah, okay. So, to answer your question about short books versus longer books: in terms of programming, I would definitely say this doesn’t really apply there.
But let me switch back to the earlier point and give you an actual example. There’s a book called As a Man Thinketh, and it’s incredibly short. You can read it quickly, and if you’re just starting your personal development journey, you might think, “This book sucks. It’s short, it doesn’t say anything, blah blah blah.” Then you read a book like Napoleon Hill’s Think and Grow Rich and think, “Oh, this guy really went into depth here.” He repeats the same core idea multiple times and approaches it from different angles.
Then later in life — and this literally happened to me — you read As a Man Thinketh again and realize there are a lot of ideas in there that other books explain in greater detail. It’s just that they’re so condensed in that little book. What I would say is: you may not understand the condensed one unless you’ve already read at least a few more books on the same subject that go into more depth. Or if you can understand it right away, then you’re probably way ahead.
Shawn: I’d dispute that. Based only on what you just said, the shorter book didn’t explain things in enough detail, while the longer books explained them better. So from my interpretation, you don’t need repetition — you just need one good explanation. I’m anti-repetition. It sounds like you’re pro-repetition, but maybe you’re conflating repetition with a more fleshed-out explanation.
Nikola: Okay, fair point. So maybe what I mean is not repetition, but more examples. Would that be okay? Because that may actually be what I’m referring to.
For example, I tend to remember examples better than just ideas in bullet-point form. We’re currently reading The DevOps Handbook, and it contains actual case studies. I tend to remember the case studies more than a list of things like “do this, do that, do this.” I remember what, for example, Google did to change something, much more than I’d remember a five-step list for DevOps transformation.
That’s just me, of course, but I like examples because they stick. If you just give me a condensed list of points, it doesn’t have the same effect.
So, going back to As a Man Thinketh, it’s a book you can technically read in maybe an hour, but to really “read” it, you’d probably have to stop every other paragraph and think about it — really think it through.
Shawn: Well, that makes the title very appropriate.
Nikola: Indeed.
Anyways, I guess we’re butchering it too much. As a summary of whether you should try book summaries versus reading actual books, I think we agree on this: maybe use them if you’re not quite sure about a book. You go on Amazon, you see good reviews, but you’re still uncertain. In that case, you can invest five minutes in reading the summary and then decide whether it’s worth investing the time to read the full book. That would be my take.
Shawn: Sure. I’m always for everyone making their own decisions, especially when it comes to their own money. So go for it if you want to.
Nikola: Okay, awesome. Anyway, thank you guys for tuning in this time, and see you again soon.
Shawn: Bye, everybody.
Thank you for listening to the DevThink podcast. To reach us for comments, show suggestions, and other feedback, contact us at info@devth.ink. Our intro music is by Rupa Deadwyler. No animals were harmed in the making of this podcast.
