Your editor was very fucking wrong.
I've never actually heard that one before, but it's so very, very true.
I think that'd be more of the author's choice, instead of the editor.
The editor is completely right in what they were saying. You just want them to be wrong, because you'd prefer to live in the fantasy world where they are wrong.
Let's say you go to get a surgery. You don't want the doctor to tell you about all the times they fucked up and what the awful consequences were. It doesn't matter that they're probably a better surgeon now, having learned from their mistakes. Psychologically, you need that person with the sharp tool poking around inside your body to be a superhuman.
To a lesser degree, the same is true for any expert. Of course everybody makes mistakes. Notice the de-personalization in the word "everybody". You can talk about the mistakes everybody makes, or those ones that many people make. If you talk about your own mistakes however, you lose the superhuman status. There may be a few situations where that somehow helps you, but not when you want to sell books.
That they won’t tell me (the patient) is quite a different question from whether they got the material from someone more experienced in their primary or continuing medical education.
Shouldn't that be more like "Let's say you're learning to be a surgeon."?
For that situation, the person they're learning from discussing problems they hit and how they solved them does sound like it would be very useful.
No. It is an exaggerated example, because I am illustrating a psychological effect.
The point is that you are consulting an expert, and you don't want that expert to tell you about all their mistakes, because your mind is now occupied with doubting that expert. It's not rational.
> For that situation, the person they're learning from discussing problems they hit and how they solved them does sound like it would be very useful.
It's useful to present common mistakes, but mentioning who made the mistake is both irrelevant and damaging.
Sometimes books are written for entry level people (to the technology or topic) and they're written in an authoritative tone. But I work with people who write books. And I read their books. I don't read them like some kind of expert oracle distributing the blessed texts. I read them as a work of documentation from a friend or colleague, so I don't really feel this veneer of expertise is necessary.
Sometimes the experts try hard to scrape away the veneer of expertise by adding side fluff like in Learn you a Haskell for Great Good. Or, Alex Crichton, who is undoubtedly an expert in Rust and compiler technology giving this talk where he keeps saying things like "it does a process called quasiquoting which doesn't make any sense to me", "I don't know what hygiene means"
Yes, you feel that way. You feel like you're a rational person who values humility, whose judgement isn't clouded by the effects that I am describing.
Well, maybe you really are that person. It doesn't matter. We cannot assume that the buyers are such noble beings.
In the situation where I'm consulting an expert - hired to fix a problem or find a solution - then I'd tend to agree with you.
But when I'm reading text from a person in my field in a subject area of interest (eg learning from a book), then I definitely want to hear of things that went wrong, and how they fixed them.
I think they're two different situations, and the one you described above isn't the correct one for a person who's bought a book to learn from.
It could just be us valuing different things in our learning though. :)
I like this analogy and I agree that the previous person saying the publisher was right, completely missed the point.
I also think this is the way the majority of tech books are written.
Can you think of another where the author goes from mistake to mistake and then finally gets it right?
I believe there is a space in tech writing for this kind of writing, but it is not something traditional book publishers believe.
This was an O'Reilly book by the way, with really good editors and a really good editoral process.
That editor was right most of the time, IMHO.
Not a book, but Raymond Hettinger often presents in this way and it's fantastic: https://www.youtube.com/watch?v=wf-BqAjZb8M
Little Lisper, Little Scheme is a conversation style that discusses a lot of false starts.
{Coders|Founders} at Work has a lot of frank talk about early mistakes people make and their pivots.
Tact means skill in dealing with other people, particularly in sensitive situations.
Tack has to do with sailing boats into the wind, and crucially "changing tack" means changing direction.
I was told not to mention the caveats, instead, render a confident image for the team many times in my career.
It's like doctors suggest their patients to use some drugs without mentioning any side effects.
It reminds me of the video[0] which asks the developer to draw red lines with blue ink, while the project manager keeps pushing the developer like "You're the expert, of course you can do draw red lines with blue ink!".
Your editor is right. Not because this information is not interesting.
But it is distracting and off-topic to go off a tangent every now and then. Especially for someone just learning the stuff, it will confuse them more than anything else.
One language that didn't go how I expected it was applescript.
The book on applescript (from o'reilly I believe) was necessarily different.
Instead writing "normal" top-down programs, applescript hooks into the OS from the side.
Many books can concentrate on what you can do, but the applescript had to do everything by example. This is because all of apple's applications expose interfaces that you have to figure out on the fly.
I had to learn a different way from that book, because it necessarily concentrated on "how" instead of "what".
When I was writing my book my editor asked me to remove any writing about mistakes and changes I made in the project for each chapter. I had a bug that appeared and I wanted to write about how I determined that and fixed it. They said the reader wants to see an expert talking, as if experts never make mistakes or need to shift from one tact to another.
But, I find I learn the most from explanations that share how your mental model was wrong initially and how you figured it out and how you did it "more right" the next time.
That's really how people build things.