"This tool won’t be appropriate for all audiobook listeners. For many, the silences matter, and removing them would degrade the quality of the book. For many, listening at 2.5x would also degrade the quality of the book. So use this tool with caution."
It's nice that this was also brought up. At least for me, even though I don't listen to audiobooks, it's too easy to become too "performance-oriented" when reading something. Meaning that ticking the box "achievement unlocked, read another book" becomes more important than what you really get out of the book. Did you now retain as much information as possible? Did you savor the work of art or just gulp it down? Ironically, if you don't use tools like these carefully, listening to books may end up being even a bigger waste of time.
I would say that to have read a text is not the goal, it's a mere implementation detail. The goal is to understand ideas which the text tries to convey.
Some texts, and usual human speech, are low-density, high-redundancy. If you can easily understand the ideas they carry, you can listen at a really high speed and still don't miss anything, and later be able to adequately recall the ideas.
Some texts are either higher-density, or talk about concepts novel enough for the listener, and it takes some time to unpack the ideas and commit them to memory. Such texts cannot be read too fast, and sometimes require going back a sentence, or a paragraph, and re-reading.
An ideal (from the efficiency standpoint) audio book device would have a speed dial to control the level of adaptive compression, like described by the linked page. It would also have controls to jump back a sentence and replay it slower.
But such device is unlikely, because I suppose that the main audience of audio books is commuting drivers, who need to keep their hands on the wheel, and their eyes on the road, so they can't properly read.
And if course I suppose that the speedup and compression are barely applicable, or need a different approach, to books read with some artistic expression (that us, most fiction worth reading).
So. Assuming we are talking about non fiction. Why would you read a book that you don't really expect to learn anything new from?
Further, your supposed use case of audio books is when you're driving, when most of your attention should be spent... Driving.
As for fiction, efficiency totally misses the point. Efficiency isn't reading Harry potter as fast as possible. Efficiency is not reading it at all.
My most charitable interpretation is that we just have different aims when it comes to consuming literature, but that still leads back to the ops point that this is basically the gamification of book reading.
> Why would you read a book that you don't really expect to learn anything new from?
Entertainment! A sufficiently wrongheaded idea advanced at length and with a measure of braggadocio can be funny as anything. Startup-culture biens-pensants are often good for this, I find.
That said, in the general case you're not wrong, and it should come as no surprise to anyone familiar with Goodhart's law that the gamification of reading produces perverse outcomes.
I wish we just didn't write low-density, high-redundancy non-fiction anymore. Especially books written in the "self-help" style where about 1% is the core message, and 99% are illustrations, examples, author's opinions, and similar.
That 99% is very easy to find online in the age of information deluge, it's probably where the author sourced it. Before the 00s, this content in a book would have been helpful. But these days, it makes sense that most people want to skip it or 2.5x it.
I used to carry a reporter notebook and take notes all the time I was listening to audio books. This made it very obvious that there's usually not a lot of information to extract from business books, leadership books, or any other kind of "coaching" books. Now I try to buy the summary variant of these books. Because ultimately, I was making my own summaries in a very time-wasteful way.
To make your own summaries you need to understand and think about the source material. I get more value from reading the book and analyzing it rather than glancing at the too-long-didn't-read version of notes somebody else wrote.
For example, the entire Checklist Manifesto book can be distilled to one sentence: break down crucial procedures into checklists and follow them. That's the core message. The 1%. On its own it means nothing to me. I can re-read it hundreds of times and it won't change my life. I'll recognize it but I won't understand it.
I need time to process my thoughts. Let the ideas marinate in my brain so to speak. I won't get much out of a book if I read it cover to cover in one sitting either.
My way to study a subject is to read not just one book, but 2 or 3 more from different authors. This way I can compare their opinions, find common things, see where they disagree, find the answers to questions I wrote down during my first read. Then I can take those ideas and make them my own.
Yes, it takes time. There's no shortcuts when I want to understand something.
As for the 99% filler content - I don't have to read it. When I read I ask myself "What's the goal of this section? What does the author try to achieve?". Often, I find a good reason. If not, I'll skip it. I can always return to it later. I have that option. I can't do that with summaries because they are lossy compression. I can't get more out of them because it's not there.
Sure, I can do my own research and look for it on the internet or interview relevant people. But at this point, I might as well write my own book.
>audiobooks, it's too easy to become too "performance-oriented" when reading something. Meaning that ticking the box "achievement unlocked, read another book" becomes more important than what you really get out of the book. Did you now retain as much information as possible?
You're expressing a common skepticism of 2x+ speedup but it misunderstands why people do it. It actually improves the presentation to 200+ wpm so the brain is more receptive to learning. The slower ~100 wpm (i.e. 1x speed) acted as a barrier to learning. I tried to explain the 2x+ advantage previously and how blind people had utilized this technique years before the general public did:
The motivations for speedup mostly applies to non-fiction audiobooks. For fiction, you may deliberately leave it at 1x because you want the deliberate pacing of the voice acting in addition to the info conveyed by the bare text.
Audio playback speed adjustment is just a tool. If you're a musician trying to learn a complicated guitar lick or drum fill, slow the music down to 0.5x or even 0.25x if that helps unlock it. If you're listening to Lord of the Rings, then playing it at 1x seems very reasonable. If you're listening to a speaker discussing inflation for an hour but keep tuning out because he talks too slow, speed him up to 4x if you have to so the information is presented at the higher speed your that brain prefers receiving it.
EDIT to replies to clarify "The slower ~100 wpm (i.e. 1x speed) acted as a barrier to learning."
This statement in isolation looks like an absolute science claim that 1x causes "zero learning" but of course that wasn't what I was saying. The context is "barrier to _optimal_ learning" for that particular reader. If 1x is too slow and makes some readers not stay mentally engaged, or abandon audiobooks, or leave podcasts/lectures in the queue and never listen to them, that's the "barrier to learning" that I'm trying to convey.
Likewise, if one needs to slow it down to 1/2 speed to comprehend difficult-to-parse text, that also meant 1x was too fast and also a barrier to optimal learning.
> The slower ~100 wpm (i.e. 1x speed) acted as a barrier to learning.
Unless there is a lot of good evidence, I am skeptical of this claim
Human children are exposed verbally to 1x human speech. Do we really think that making teachers talk faster will improve learning and retention?
Also, according to linguistics, I believe pretty much human languages transmit close to the same bit rate (some languages have longer more descriptive words, some have shorter words, but by and large they average out).
Throughout our evolution, we have been exposed to 1x speech.
My guess would be that are brains don’t have a learning block to 1x speech.
It maybe doesn't come naturally to most people to be able to take in information from speech at high speeds, but it is definitely possible to learn. I am blind, and use a screen reader. My screen reader's voice is many times faster than normal human speech. (I don't know exactly how much faster, but most people can't understand a word of it.) I also listen to non-fiction podcasts and books at 1.5-2x speed, although I almost always listen to fiction at normal speed unless the reader is painfully slow.
Lazy people work the hardest. It's an up front investment for a big payoff later when you can grok your code in scannable blocks instead of having to read a dozen lines and pause to contemplate what they mean, then juggle them in your memory with other blocks until you find the block you're looking for.
Comments allow for a high-level view of your code, and people who don't value that probably on average have a slower overall output.
What you write in your first para is so self evidently true, at least to me.
I simply cannot comprehend the mindset that views comments as unnecessary. Or worse, removes existing useful comments in some quest for "self-documenting" purity.
I've worked in some truly huge codebases (40m LOC, 20k commits a week, 4k devs) so I think I have a pretty good idea of what's easy vs hard in understanding unfamiliar code.
As the late Chesterton said, "Don't ever take a fence down until you know the reason why it was put up."
A lot of people think comments are descriptive rather than prescriptive. They think a comment is the equivalent of writing "Fence" on a plaque and nailing it to the fence. "It's a fence," they say, "You don't need a sign to know that."
Later, when the next property owner discovers the fence, they are stumped. What the hell was this put here for? A prescriptive comment might have said, "This was erected to keep out chupacabras," answering not what it is, but why.
You might know about the chupacabras, but if you don't pass it on then you clearly don't care about who has to inherit your property.
What's amazingly funny is that many people think this is a positive, because they ascribe more value to working hard than to achieving results. I even thought your comment was going to go that way when I first read it.
I'd say it's also a question of team size and organization. Are you a singular developer, or in a large team, writing enterprise software that should be easy to pick up for someone reading the code 10 years later etc.
Having studied mostly OOP/Java at the uni, and been using mostly C# at work, I realized I might actually start to find programming fun again through Go. I've studied it a bit recently and this idea of interfaces with composition over inheritance etc. made somehow a lot more sense to me, and gave me this boost to try and learn it more because it felt so enjoyable. Not even with some practical problem at hand to solve, but just on an abstract level, not having to deal with OOP classes and inheritance and all the things. Now I just need to find a Go job and get my feet a little more wet. ;P I'm talking about Go because it gives me similar feelings as Rust, but Rust I have a lot less experience with. I hope there's a similar fun and excitement to be found in Rust as well, after unlearning some old habits.
Go is fun at first, and then it becomes soul sucking. It's all boiler plate. Many large scale projects have a lack of adequate unit testing, so large code bases are particularly painful to maintain. I attribute this lack of tests due to how the code needs to be structured, you have to needlessly add 'interfaces' throughout your code to accomplish things.
Go has it's strengths, but IMO fun isn't one of them. It turns into soul-suck quickly.
I'm in the same position as OP and was wondering the same thing; finding a job using Go. Is the bloat that you see the most related to error checking? If not what else is it?
The bloat is mostly related to mocking and making a fake client for everything for unit tests, and the practices you have to follow to make that actually work.
In Python or Java, you can do something like:
class:
f1():
self.some_api_call()
<process api call here>
test_class extends class
some_api_call():
<mock definition>
In go, you cannot do this. Fair enough, but everyone writes object-style code because it's easier and there's less boiler plate. If you do this, you can't write tests.
Instead, you have to do something like:
class:
apiMethod = nil
f1():
self.apiMethod()
<process api call>
And assign apiMethod when you create the instance of the object; there are no constructors because they're not traditional objects, you need to create a factor method (boiler plate) or build the struct by hand (boiler plate). None of this is terribly challenging in and of itself, but if you work on large code bases, nobody did this because it's extra work, and now you have to refactor it because you want to make a change to the critical business logic and prove you're not introducing a regression (a constraint the l33t coders before you didn't have because they get to go fast and break things).
And finally, often times the thing you need to mock is in someone else's package, and it doesn't implement an interface, or the thing you need to mutate is private, etc, etc. You end up need to mock half of a package sometimes.
None of this is insurmountable, but when you do it day in and day out for years like I did, it's a real slog, and it sucks your soul out of your body. It wasn't uncommon for me to spend literally 20x as long refactoring and implementing tests as it was to ship features. If you look at some unit tests from large go projects, you'll see stuff like struct{struct{struct{struct{...}}},struct{struct{struct{...}}}} because so much stuff needs to be mocked up. And since interfaces are disjointed from classes, you won't know with certainty which methods you need to needlessly mock for your mock class until you try to compile, because the interface is defined somewhere else and not attached to a base class, it's just a definition floating out there in the source somewhere.
I'm reposting your message with the code formatted as you had entered it (the original white space use is still visible in the html source code; I've just indented it so that HN recognizes it as preformatted):
---
The bloat is mostly related to mocking and making a fake client for everything for unit tests, and the practices you have to follow to make that actually work.
In Python or Java, you can do something like:
class:
f1():
self.some_api_call()
<process api call here>
test_class extends class
some_api_call():
<mock definition>
In go, you cannot do this. Fair enough, but everyone writes object-style code because it's easier and there's less boiler plate. If you do this, you can't write tests.
Instead, you have to do something like:
class:
apiMethod = nil
f1():
self.apiMethod()
<process api call>
And assign apiMethod when you create the instance of the object; there are no constructors because they're not traditional objects, you need to create a factor method (boiler plate) or build the struct by hand (boiler plate). None of this is terribly challenging in and of itself, but if you work on large code bases, nobody did this because it's extra work, and now you have to refactor it because you want to make a change to the critical business logic and prove you're not introducing a regression (a constraint the l33t coders before you didn't have because they get to go fast and break things).
And finally, often times the thing you need to mock is in someone else's package, and it doesn't implement an interface, or the thing you need to mutate is private, etc, etc. You end up need to mock half of a package sometimes.
None of this is insurmountable, but when you do it day in and day out for years like I did, it's a real slog, and it sucks your soul out of your body. It wasn't uncommon for me to spend literally 20x as long refactoring and implementing tests as it was to ship features. If you look at some unit tests from large go projects, you'll see stuff like struct{struct{struct{struct{...}}},
struct{struct{struct{...}}}} because so much stuff needs to be mocked up. And since interfaces are disjointed from classes, you won't know with certainty which methods you need to needlessly mock for your mock class until you try to compile, because the interface is defined somewhere else and not attached to a base class, it's just a definition floating out there in the source somewhere.
I often wonder what would currently be a way to work in a more enterprisey environment and actually make stuff a little bit more fun and not all "abstract factories" etc. I'm talking TypeScript/C#/.NET Core type of stuff, maybe with Vue. What's the "new Clean Code"? Might just learn Go next or something.
Indeed, we should ban people from bad universities from competing for our jobs. We certainly wouldn’t want anybody who hasn’t graduated high school to be working with us. They might say the wrong things or have the wrong attitudes.
If I knew this was my last day alive, I wouldn't be here sitting at work. Living every minute as if it was your last is actually pretty difficult to do. Or perhaps it means coming up with the understanding that it's not worth your time to stress about work. Just do the work and focus on what makes you happy. Maybe even quit and live a simpler life with less income? But you usually have houses to pay, kids to raise... it can become a prison of its own kind. There's always some magical reward waiting just around the corner, be it retirement, kids moving out, when you can finally focus on yourself again. How does one truly live every moment like it was their last?
As said before, most people are "nobodies". A small number people just happen to be both brilliant enough and be at the right place at the right time with some luck involved to strike some type of more famous success for example, and also happen to have all the time in their hands to do just their one passion.
I used to compare myself to others all the time, thinking about who did what by what age etc., but in reality it's just useless and fake. It used to be that maybe you compared yourself to the other kid at school who was good at something. Now you compare yourself to somebody who made it famous on the internet who's like the "best in the world" at something. Makes comparisons like that horrible for your mental health. These days I'm just happy to have decently paying job so I can pay my taxes, which mostly contribute to many good things in my country, meaning I can still be a positive force.
