[m1keil]

> I learned a ton from my DE. Like, really, a ton. Before that, I had been writing on various blogs for about a decade, but writing online is all about being direct because most people don’t have time. With a book, it’s different. People made a deliberate decision to buy your book. Now, it’s your job to bring them somewhere valuable. And if that takes time (meaning more words), so be it.

I have a hard time with this point. It feels to me like a lot of books have A LOT of unecassery padding all over the place.

The example of taking 28 words and turning it to 120 is pretty good at showing this. The first paragraph is totally pointless - we are reading a book about 100 most common mistakes, obviously this mistake is very common, how did this increased the value?

Then we have another line that explaining what happens in the code, which is totally useless because the code is super trivial.

Then the code, with more explanations on the side as if the previous line was not clear.

And only after that we get to the crux of the issue.

I understand that book publishers feel they need to justify the price of a book by reaching the 300p mark in some or other way, but in my way this only makes the book worse.

[teivah]

It's your opinion, nothing wrong with it. Let me try to see if I can make you change it at least a bit.

> The first paragraph is totally pointless - we are reading a book about 100 most common mistakes, obviously this mistake is very common, how did this increased the value?

There are different levels in terms of common mistakes, and this one was probably one that all the devs did at some point. So I think highlighting the fact it's a frequent one does make sense.

> Then we have another line that explaining what happens in the code, which is totally useless because the code is super trivial.

I have a rule: always explain the intention of the code. Even if it's 5 lines of code, it helps the reader to better understand what we will want to highlight.

> Then the code, with more explanations on the side as if the previous line was not clear.

The explanations on the side do not impact the size of the book so the argument doesn't hold. I did it in many code snippets to highlight where the reader needs to focus.

> I understand that book publishers feel they need to justify the price of a book by reaching the 300p mark in some or other way

This is more about guiding the readers, making sure the expectations are crystal clear and that they can follow me throughout an explanation. You judge it as a criteria to justify the price of the book, but it's not the real reason. At least not for my book and I'm sure it's the case for many others :)

[m1keil]

> This is more about guiding the readers, making sure the expectations are crystal clear and that they can follow me throughout an explanation.

Sure, but this holds true for the blog version as well, right?

To be clear, I'm not advocating for The Little Schemer version, and am not arguing that the blog version is the best it can be, but surely we can agree that book padding phenomenon does exist.

By the way, I have read parts of your book over at O'Reilly Learning, and I do think it is a good book. So I'm not trying to take a dump on your work. My criticism is aimed at publishers.