{"id":4840,"date":"2026-04-14T17:23:28","date_gmt":"2026-04-14T17:23:28","guid":{"rendered":"https:\/\/nikola-breznjak.com\/blog\/?p=4840"},"modified":"2026-04-14T17:23:28","modified_gmt":"2026-04-14T17:23:28","slug":"are-book-summaries-worth-it","status":"publish","type":"post","link":"https:\/\/nikola-breznjak.com\/blog\/devthink\/are-book-summaries-worth-it\/","title":{"rendered":"Are Book Summaries Worth It?"},"content":{"rendered":"<h2>TL;DR<\/h2>\n<p>Every now and then, a \u201cshortcut\u201d 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. <em>Yup, guilty as charged.<\/em> \ud83d\ude48<\/p>\n<p>You&#8217;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.<\/p>\n<p>But is it actually useful?<\/p>\n<p>My take is that <strong>summaries can be helpful<\/strong>, but only in a very specific role: <strong>as a filter, not as a replacement<\/strong>. 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. \ud83e\udd37\u200d\u2642\ufe0f<\/p>\n<p>As usual, the truth is somewhere in the messy middle.<\/p>\n<p>If you prefer audio content, you can listen to the full episode <a href=\"http:\/\/www.nikola-breznjak.com\/devthink\/episode_015_book_summaries.mp3\">here<\/a>, and below I&#8217;ll provide a TL;DR (yeah, summarries of summaries of summaries \ud83d\ude05)<\/p>\n<h2>The appeal of book summaries<\/h2>\n<p>I\u2019ll admit it: I was intrigued by the idea.<\/p>\n<p>I tried Blinkist for a while because, like many people, I love reading but I\u2019m not exactly the fastest reader on the planet (<em>even though I completed the speed reading courses, read books on the topic, etc.<\/em>). The idea of being able to \u201cconsume\u201d more books in less time felt like a superpower. Read the essentials, move on, repeat. Nice and efficient \ud83d\udcaa<\/p>\n<p>But after using it, I started feeling that something was off.<\/p>\n<p>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: <strong>\u201cOkay&#8230; and?\u201d<\/strong><\/p>\n<p>It felt like I had skimmed the skeleton of an idea without really absorbing it.<\/p>\n<p>That, to me, is the core weakness of summaries. They can tell you what a book is <em>about<\/em>, but they often fail to give you the experience of <strong>thinking through the book<\/strong>.<\/p>\n<p>And that part, for me, matters more than anything.<\/p>\n<h2>A summary can help you choose the right book<\/h2>\n<p>That said, I don\u2019t think book summaries are useless.<\/p>\n<p>Quite the opposite.<\/p>\n<p>I think they\u2019re actually pretty good as a <strong>decision-making tool<\/strong>.<\/p>\n<p>Sometimes a book has a great title, a compelling cover, and glowing reviews, but you still don\u2019t know whether it\u2019s 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.<\/p>\n<p>A summary can help answer a simple question: <strong>\u201cDo I want to invest my time in this book?\u201d<\/strong><\/p>\n<p>And that\u2019s a perfectly valid use case.<\/p>\n<p>Because let\u2019s be honest: reading every interesting-sounding book cover to cover just isn\u2019t viable.<\/p>\n<h2>The real value of longer books<\/h2>\n<p>Where things got interesting in the episode is when we started talking about repetition.<\/p>\n<p>Shawn\u2019s point was that many books could probably be much shorter. You\u2019ve probably seen those reviews on Amazon too: <em>\u201cThis should\u2019ve been a 50-page book, but they stretched it to 300.\u201d<\/em> And honestly, he\u2019s not wrong. Plenty of books are padded.<\/p>\n<p>But I argued that with good books, repetition is not always a waste of paper.<\/p>\n<p>Sometimes repetition is actually <strong>reinforcement<\/strong>.<\/p>\n<p>Or maybe, more accurately, it\u2019s not repetition itself that matters; it\u2019s <strong>the repeated explanation through different examples, angles, and stories<\/strong>.<\/p>\n<p>That\u2019s a subtle but important difference.<\/p>\n<p>For example, I mentioned <strong>As a Man Thinketh<\/strong>, which is a very short book. So short, in fact, that if you read it early in your personal development journey, you might think, \u201cThat\u2019s it? This is what all the fuss is about?\u201d<\/p>\n<p>But later, after reading other books that explore similar ideas in greater depth, you come back to it and suddenly realize there\u2019s more packed into those few pages than you first noticed.<\/p>\n<p>In other words:<\/p>\n<ul>\n<li>Some short books are dense and powerful.<\/li>\n<li>Some long books are bloated.<\/li>\n<li>And some long books earn their length by helping ideas actually stick.<\/li>\n<\/ul>\n<h2>Examples beat bullet points<\/h2>\n<p>At one point, we also touched on something I\u2019ve noticed about how I learn best: I tend to remember <strong>examples<\/strong> much more than abstract lists.<\/p>\n<p>Take a book like <strong>The DevOps Handbook<\/strong>. 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.<\/p>\n<p>That\u2019s why summaries can feel incomplete.<\/p>\n<p>A summary may give you the \u201cwhat,\u201d but often it strips away the \u201cwhy this matters\u201d and the \u201chow this plays out in real life.\u201d<\/p>\n<p>And that\u2019s usually where the real learning happens.<\/p>\n<p>It\u2019s one thing to read:<\/p>\n<blockquote>\n<p>do steps one, two, three, four, five<\/p>\n<\/blockquote>\n<p>It\u2019s another thing entirely to see how those ideas played out in practice, where they worked, where they didn\u2019t, and what tradeoffs were involved.<\/p>\n<p>That extra context is often the difference between <strong>recognizing<\/strong> an idea and actually <strong>understanding<\/strong> it.<\/p>\n<h2>What about technical books?<\/h2>\n<p>Since this is DevThink, Shawn asked the obvious question: does any of this apply to technical books?<\/p>\n<p>And here I think the answer is pretty straightforward: <strong>Not really.<\/strong><\/p>\n<p>Or at least, not in the same way.<\/p>\n<p>You probably can\u2019t 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.<\/p>\n<p>A summary might still help you decide whether a technical book seems relevant, but it\u2019s not going to replace actually working through the material.<\/p>\n<p>You can\u2019t 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.<\/p>\n<h2>So, are book summaries worth it?<\/h2>\n<p>My conclusion is pretty simple:<\/p>\n<p><strong>Yes, but only if you use them for the right job.<\/strong><\/p>\n<p>Use summaries to:<\/p>\n<ul>\n<li>preview a book<\/li>\n<li>decide whether it\u2019s worth your time<\/li>\n<li>refresh your memory after reading the full book<\/li>\n<\/ul>\n<p>Don\u2019t use summaries to:<\/p>\n<ul>\n<li>replace deep reading entirely<\/li>\n<li>assume you\u2019ve \u201cread the book\u201d<\/li>\n<li>expect real understanding from a compressed list of takeaways alone<\/li>\n<\/ul>\n<p>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.<\/p>\n<p>So no, I don\u2019t think book summaries are a magic shortcut.<\/p>\n<p>But as a smart filtering tool? Absolutely.<\/p>\n<h2>Full Transcript<\/h2>\n<p><strong>Episode:<\/strong> DevThink Podcast \u2013 Book Summaries<br \/>\n<strong>Audio:<\/strong> <a href=\"http:\/\/www.nikola-breznjak.com\/devthink\/episode_015_book_summaries.mp3\">Listen here<\/a><\/p>\n<p><strong>Shawn:<\/strong> Hey, everybody. Welcome back to the DevThink podcast with your usual hosts, Shawn and Nikola. Today\u2019s 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\u2019ve had more experience with these than I have.<\/p>\n<p><strong>Nikola:<\/strong> Yes. I actually tried a service called Blinkist. Honestly, at first, I liked it. I liked the idea behind it. You think, \u201cOh, awesome.\u201d I mean, I like to read a lot. But then again, I\u2019m 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\u2019t getting much value out of it. You read a summary and then you\u2019re like, \u201cOkay, wait, so I read these 10 bullet points&#8230; now what?\u201d<\/p>\n<p>Although, to be fair \u2014 and honestly, this will probably be our shortest episode ever \u2014 I do think book summaries are useful when you\u2019re trying to decide whether or not you actually want to read the full book. Here\u2019s 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\u2019s where I stand.<\/p>\n<p>What do you think, Shawn?<\/p>\n<p><strong>Shawn:<\/strong> That\u2019s 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\u2019s the old phrase, \u201cDon\u2019t judge a book by its cover,\u201d and if you can\u2019t 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\u2019s just not practical. So I think it\u2019s a good idea if you want to decide whether to get the book.<\/p>\n<p>On the other hand, when you mentioned repetition, I immediately thought, \u201cYeah,\u201d but then you said that was a good thing, and I was like, \u201cWhoa, we\u2019re completely opposite there.\u201d Because for you, repetition helps you learn it throughout the course of the book. But from my perspective, a lot of books \u2014 and I\u2019ve read a lot of reviews on Amazon \u2014 are described as books that should have been 50 pages, but got padded out to 300 because no one\u2019s going to publish or buy a 50-page book. Every book has to be 300 or 400 pages to get sold.<\/p>\n<p>So I\u2019m thinking, if you can take out all the repetition and it becomes something I can read in under an hour, maybe that\u2019s a good thing.<\/p>\n<p>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\u2019m going to go out on a limb and say you couldn\u2019t do this with, say, a programming language book. You can\u2019t 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?<\/p>\n<p><strong>Nikola:<\/strong> Yeah, okay. So, to answer your question about short books versus longer books: in terms of programming, I would definitely say this doesn\u2019t really apply there.<\/p>\n<p>But let me switch back to the earlier point and give you an actual example. There\u2019s a book called <em>As a Man Thinketh<\/em>, and it\u2019s incredibly short. You can read it quickly, and if you\u2019re just starting your personal development journey, you might think, \u201cThis book sucks. It\u2019s short, it doesn\u2019t say anything, blah blah blah.\u201d Then you read a book like Napoleon Hill\u2019s <em>Think and Grow Rich<\/em> and think, \u201cOh, this guy really went into depth here.\u201d He repeats the same core idea multiple times and approaches it from different angles.<\/p>\n<p>Then later in life \u2014 and this literally happened to me \u2014 you read <em>As a Man Thinketh<\/em> again and realize there are a lot of ideas in there that other books explain in greater detail. It\u2019s just that they\u2019re so condensed in that little book. What I would say is: you may not understand the condensed one unless you\u2019ve 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\u2019re probably way ahead.<\/p>\n<p><strong>Shawn:<\/strong> I\u2019d dispute that. Based only on what you just said, the shorter book didn\u2019t explain things in enough detail, while the longer books explained them better. So from my interpretation, you don\u2019t need repetition \u2014 you just need one good explanation. I\u2019m anti-repetition. It sounds like you\u2019re pro-repetition, but maybe you\u2019re conflating repetition with a more fleshed-out explanation.<\/p>\n<p><strong>Nikola:<\/strong> 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\u2019m referring to.<\/p>\n<p>For example, I tend to remember examples better than just ideas in bullet-point form. We\u2019re currently reading <em>The DevOps Handbook<\/em>, and it contains actual case studies. I tend to remember the case studies more than a list of things like \u201cdo this, do that, do this.\u201d I remember what, for example, Google did to change something, much more than I\u2019d remember a five-step list for DevOps transformation.<\/p>\n<p>That\u2019s just me, of course, but I like examples because they stick. If you just give me a condensed list of points, it doesn\u2019t have the same effect.<\/p>\n<p>So, going back to <em>As a Man Thinketh<\/em>, it\u2019s a book you can technically read in maybe an hour, but to really \u201cread\u201d it, you\u2019d probably have to stop every other paragraph and think about it \u2014 really think it through.<\/p>\n<p><strong>Shawn:<\/strong> Well, that makes the title very appropriate.<\/p>\n<p><strong>Nikola:<\/strong> Indeed.<\/p>\n<p>Anyways, I guess we\u2019re 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\u2019re not quite sure about a book. You go on Amazon, you see good reviews, but you\u2019re still uncertain. In that case, you can invest five minutes in reading the summary and then decide whether it\u2019s worth investing the time to read the full book. That would be my take.<\/p>\n<p><strong>Shawn:<\/strong> Sure. I\u2019m always for everyone making their own decisions, especially when it comes to their own money. So go for it if you want to.<\/p>\n<p><strong>Nikola:<\/strong> Okay, awesome. Anyway, thank you guys for tuning in this time, and see you again soon.<\/p>\n<p><strong>Shawn:<\/strong> Bye, everybody.<\/p>\n<p>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.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>TL;DR Every now and then, a \u201cshortcut\u201d to learning shows up and promises to save us time, money, and maybe even a bit of guilt about the unread&hellip;<\/p>\n","protected":false},"author":1,"featured_media":4842,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[65],"tags":[],"class_list":["post-4840","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-devthink"],"_links":{"self":[{"href":"https:\/\/nikola-breznjak.com\/blog\/wp-json\/wp\/v2\/posts\/4840","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/nikola-breznjak.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/nikola-breznjak.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/nikola-breznjak.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/nikola-breznjak.com\/blog\/wp-json\/wp\/v2\/comments?post=4840"}],"version-history":[{"count":0,"href":"https:\/\/nikola-breznjak.com\/blog\/wp-json\/wp\/v2\/posts\/4840\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/nikola-breznjak.com\/blog\/wp-json\/wp\/v2\/media\/4842"}],"wp:attachment":[{"href":"https:\/\/nikola-breznjak.com\/blog\/wp-json\/wp\/v2\/media?parent=4840"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/nikola-breznjak.com\/blog\/wp-json\/wp\/v2\/categories?post=4840"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/nikola-breznjak.com\/blog\/wp-json\/wp\/v2\/tags?post=4840"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}