Is the OCP book the same buggy as the OCA one? (Java OCA 8 Programmer I Study Guide, Sybex)

[Andrew Polansky]

I do not want to open a new thread, so I will ask here. Is the OCP book the same buggy as the OCA one? I am barely in the middle of the Java OCA 8 Programmer I Study Guide and I found already a bunch of significant mistakes. Virtually I am checking every method signature in the book, because there is so many wrong ones in the book as well as in flash cards that I have lost my trust in that book. The book is still a good guide, but emphasis must be put on word "guide". I would never recommend anybody to actually start learning from it due to all the errors. Without a respected supplement book one can learn many false things.

(This post originated in this topic)

[Roel De Nijs]

Adam Scheller wrote:I do not want to open a new thread, so I will ask here.

I opened one for you as it's a totally different discussion

Adam Scheller wrote:Is the OCP book the same buggy as the OCA one? I am barely in the middle of the Java OCA 8 Programmer I Study Guide and I found already a bunch of significant mistakes. Virtually I am checking every method signature in the book, because there is so many wrong ones in the book as well as in flash cards that I have lost my trust in that book. The book is still a good guide, but emphasis must be put on word "guide". I would never recommend anybody to actually start learning from it due to all the errors. Without a respected supplement book one can learn many false things.

I don't agree with your criticism! We had very recently a similar discussion about why technical books (and certification study guides in particular) have such an (extensive) errata overview. What's acceptable and what's not? Is a book with a publicly available overview with a bunch of errata better than a book without such an overview? Is a book with an errata overview of only 10 items always a better choice than one with an overview containing 100 items? It's very understandable to answer "Definitely" to that last question, but that's definitely not always true! If you want to know why and/or if you are interested in why I don't agree with your criticism, just have a read of that discussion

Kind regards,
Roel

[Andrew Polansky]

I did read many technical books and this one is pretty unique in matter of errors. Typos and other minor things are totally understandable, and I really don't care about such things. But errors in this book look like it was never reviewed. Those are not minor mistakes, but things that hit the eyes.

For example, take a look at following examples from my original post. How such things could got unnoticed? No single line of code below makes any logical sense.

int indexOf(char ch, index fromIndex)

int indexOf(String str, index fromIndex)

int substring(int beginIndex)

int substring(int beginIndex, int endIndex)

String toLowerCase(String str)

String toUpperCase(String str)

A few months ago I was doing a technical review for a book from Manning. We were reviewing new chapters every few months. We were running example codes, comparing things with documentation, scanning every line of written text. Manning always picks up beginners as well as advanced users to review the books from different perspectives. We found several various errors thorough the time when the book was being written. In case of this book, it looks like such review never took place.

What I can't understand is how such mistakes weren't found? For me it looks like nobody ever did a technical review before releasing this book. I can understand that authors could not find such mistakes. It's the same concept as why developers are bad on testing their on code. What I can't understand is why technical reviews didn't catch that? Or maybe there was no review at all?

Public and honest errata is certainly good thing. But does it justify that a book was carelessly released without proper review? If yes, then we can ask primary school students to write tech books and say those are great books because they have 100 pages long public erratas.

[Roel De Nijs]

Adam Scheller wrote:What I can't understand is how such mistakes weren't found? For me it looks like nobody ever did a technical review before releasing this book. I can understand that authors could not find such mistakes. It's the same concept as why developers are bad on testing their on code. What I can't understand is why technical reviews didn't catch that? Or maybe there was no review at all?

I was not involved in the creation process of this study guide, so I don't know if this study guide was reviewed by one or more technical reviewers. But a quick look at the acknowledgements section reveals the book was definitely tech reviewed and tech proofed. First of all, technical reviewers are humans, and humans still make mistakes. And you assume that such mistakes weren't found, but maybe they were found and reported by the technical reviewers. In the book creation process many people are involved and some of them don't have a Java (or technical) background, so (new) mistakes might slip back into the book.

Adam Scheller wrote:A few months ago I was doing a technical review for a book from Manning. We were reviewing new chapters every few months. We were running example codes, comparing things with documentation, scanning every line of written text. Manning always picks up beginners as well as advanced users to review the books from different perspectives. We found several various errors thorough the time when the book was being written.

Although I'm pretty sure you did an awesome job as a technical reviewer, I'm convinced readers will still find various (technical) errors. And if it's just a technical book, many of them will go unnoticed. But for a certification study guide, readers are very focused while reading because a dot or even a space can make a difference. I am a technical reviewer of a few certification study guides too. And although I'm very meticulous with a great eye for detail (not bragging here, that's what authors say about me in the acknowledgements sections ), when the study guide is published there are still (many) reported errata items.
And these study guides are a first edition, so they are completely written from scratch. If you have a look at the K&B7 study guide (which is the 4th edition I believe), there are still plenty of reported errata items. So even after being read by several technical reviewers for every edition of this book, readers still find mistakes in sections which are unchanged in different editions.

Adam Scheller wrote:Public and honest errata is certainly good thing. But does it justify that a book was carelessly released without proper review? If yes, then we can ask primary school students to write tech books and say those are great books because they have 100 pages long public erratas.

That's not what I said at all! I just wanted to note that judging study guides solely on their errata could result in a misrepresentation (and thus a wrong choice). And honestly, if I have two study guides and both have 10 errata items, I prefer the book with such obvious errors as the one you have posted. And the reason is very simple: it's really so obvious that it's a mistake. And it's a mistake which can be easily fixed too, even by a Java greenhorn/newbie. You write a code snippet using the wrong method signature, the compiler complains, you verify the API documentation and you know the correct method signature. But if the study guide would have an incorrect explanation about how objects are created or garbage collection does its job, it would be much harder to spot (and fix) the mistake (certainly for a Java greenhorn/newbie).

Kind regards,
Roel

[Andrew Polansky]

Roel De Nijs wrote:I was not involved in the creation process of this study guide, so I don't know if this study guide was reviewed by one or more technical reviewers. But a quick look at the acknowledgements section reveals the book was definitely tech reviewed and tech proofed. First of all, technical reviewers are humans, and humans still make mistakes. And you assume that such mistakes weren't found, but maybe they were found and reported by the technical reviewers. In the book creation process many people are involved and some of them don't have a Java (or technical) background, so (new) mistakes might slip back into the book.

Technical reviews are landing on authors hands. Those documents are not about formatting and punctuation that are fixed by non-tech people, but about mistakes in content that must be fixed by authors themselves. For some reason, I can't believe that either Jeanne or Scott would ignore reports about such mistakes

Roel De Nijs wrote:Although I'm pretty sure you did an awesome job as a technical reviewer, I'm convinced readers will still find various (technical) errors. And if it's just a technical book, many of them will go unnoticed. But for a certification study guide, readers are very focused while reading because a dot or even a space can make a difference. I am a technical reviewer of a few certification study guides too. And although I'm very meticulous with a great eye for detail (not bragging here, that's what authors say about me in the acknowledgements sections ), when the study guide is published there are still (many) reported errata items.
And these study guides are a first edition, so they are completely written from scratch. If you have a look at the K&B7 study guide (which is the 4th edition I believe), there are still plenty of reported errata items. So even after being read by several technical reviewers for every edition of this book, readers still find mistakes in sections which are unchanged in different editions.

Of course the readers will find various technical errors, but after solid and focused technical reviews the number of mistakes in a book is much smaller, and most importantly, big mistakes have much bigger chance to get caught. Remember that I have in mind mistakes that are obvious and very visible like those method signatures, not typos or missing semicolons that can survive several editions of a book.

Roel De Nijs wrote:That's not what I said at all! I just wanted to note that judging study guides solely on their errata could result in a misrepresentation (and thus a wrong choice). And honestly, if I have two study guides and both have 10 errata items, I prefer the book with such obvious errors as the one you have posted. And the reason is very simple: it's really so obvious that it's a mistake. And it's a mistake which can be easily fixed too, even by a Java greenhorn/newbie. You write a code snippet using the wrong method signature, the compiler complains, you verify the API documentation and you know the correct method signature. But if the study guide would have an incorrect explanation about how objects are created or garbage collection does its job, it would be much harder to spot (and fix) the mistake (certainly for a Java greenhorn/newbie).

Erratas aren't helpful in book selections at all, they are useful only after purchase. When I look at two study guides with 10 errata items, I have no idea what mistakes they caught. You said that you would buy one with obvious mistakes in errata. But you can't be sure that this book doesn't contain incorrect explanations about how objects are created or how GC works. Maybe people didn't find those mistakes yet, or errata wasn't yet updated.


This discussion went in a little other direction than I originally asked. So, let's clarify things

My question was "is the OCP book the same buggy as the OCA one?". I mentioned about these hitting-in-the-eyes mistakes because I wanted to know if OCP book did something to get less of mistakes like those. It's really a first I read that is so filled with such obvious and visible mistakes.

What I didn't say is that this book is bad, so we don't have to discuss that it's honest errata is good and makes it a better book. I went a little too far with saying that "I have lost my trust in that book", it was certainly bad words choice. This book is really helpful, well organized and explanations are done in a very clear way. It can be seen that Jeanne and Scott have knowledge and they know what they are talking about, and they certainly put a lot of hard work to write it. What made me sad is just how such mistakes could slip in?

I just hope that Jeanne and Scott are not angry on me now

[Roel De Nijs]

Adam Scheller wrote:Technical reviews are landing on authors hands. Those documents are not about formatting and punctuation that are fixed by non-tech people, but about mistakes in content that must be fixed by authors themselves. For some reason, I can't believe that either Jeanne or Scott would ignore reports about such mistakes

That's actually the point I was trying to make, but clearly I failed miserably! Although authors are responsible for the final product, it might not be their fault at all. It could be introduced during copy-editing, maybe a wrong version of the manuscript was used at a given point, a search/replace action replaced a few false hits, or a million other things could have caused these mistakes to have slipped through the cracks.
For example, I know a little story about a copy-editor who thought it would be very helpful to the author to replace all boolean occurences with Boolean when it's at the beginning of a sentence. Or in code snippets split some long String literals by simply hitting the Enter key in the middle of the literal. It might not be so obvious as those incorrect method signatures, but it clearly shows how fast mistakes can be introduced into a book.

Adam Scheller wrote:What I didn't say is that this book is bad

If you state about a study guide that "I have lost trust in that book", "I would not recommend it", and "you need another respected complementary book" it is pretty obvious for me you think "the book is bad". But that might just be my interpretation, although I would say similar things about a book if I think it was bad.

[Ahmed Bin S]

Roel De Nijs wrote:

Adam Scheller wrote:What I didn't say is that this book is bad

If you state about a study guide that "I have lost trust in that book", "I would not recommend it", and "you need another respected complementary book" it is pretty obvious for me you think "the book is bad". But that might just be my interpretation, although I would say similar things about a book if I think it was bad.

If I buy a Ferrari that has a beautiful design and beautifully manufactured parts, but it is assembled poorly, am I saying the Ferrari is good or bad? I would say I am saying both - the Ferrari is in principle a great car, but the assembling has resulted in it being a bad car to drive.

So I think you're both right - Adam is right because he is saying this is a good book that has been let down because of all these errors, and you're right because you're saying Adam is effectively saying this is a bad book that should be avoided because all the errors have spoilt an otherwise good book!

[Jeanne Boyarsky]

Adam,
Our OCP errata list is online so you can look at the list and decide for yourself if it is a dealbreaker. As Roel said, all cert books have errata. Some of which is embarrassing like your example. The difference is that some books (like us and Kathy/Bert's) disclose everything found and others don't. Personally, I'd far rather have a list than have unknown things wrong!

In case you are curious, we did have two tech reviewers and a non-technical copy editor. We did fix everything they found. Some of the errors were introduced during that fixing process. Some were introduced during rendering. But most are our (the author's) doing. It's like a production bug. The developers, QA, etc all had the opportunity to find them and they slipped through. For other books (including K&B 7), Roel and I have been part of the tech review process. It's surprisingly difficult to find everything. And it is harder in a cert book. For K&B 7, there were some errata that survived multiple editions of the book. I assure you that our reviewers did catch many things and they were all fixed.

At work, I was the SQE (software quality engineer) as part of my job for a few years. And I've always strived to make an error free product - whether it is code or a book. It's harder than it looks for writing a book!

I'm not mad. It's good to have discussions with readers. I forgot if it was Kathy Sierra or Mike Cohn that said it is good for readers to have strong opinions - whether positive or negative.

[Andrew Polansky]

Roel De Nijs wrote:That's actually the point I was trying to make, but clearly I failed miserably! Although authors are responsible for the final product, it might not be their fault at all. It could be introduced during copy-editing, maybe a wrong version of the manuscript was used at a given point, a search/replace action replaced a few false hits, or a million other things could have caused these mistakes to have slipped through the cracks.
For example, I know a little story about a copy-editor who thought it would be very helpful to the author to replace all boolean occurences with Boolean when it's at the beginning of a sentence. Or in code snippets split some long String literals by simply hitting the Enter key in the middle of the literal. It might not be so obvious as those incorrect method signatures, but it clearly shows how fast mistakes can be introduced into a book.

That makes a sense.

Roel De Nijs wrote:

Adam Scheller wrote:What I didn't say is that this book is bad

If you state about a study guide that "I have lost trust in that book", "I would not recommend it", and "you need another respected complementary book" it is pretty obvious for me you think "the book is bad". But that might just be my interpretation, although I would say similar things about a book if I think it was bad.

As I mentioned in my previous post, I have made a poor decision of words choice. I would still suggest to pickup an extra book during learning process, but it is what I would say about any book. Learning from a single source is not the most effective method.

Ahmed Bin S wrote:

Roel De Nijs wrote:

Adam Scheller wrote:What I didn't say is that this book is bad

If you state about a study guide that "I have lost trust in that book", "I would not recommend it", and "you need another respected complementary book" it is pretty obvious for me you think "the book is bad". But that might just be my interpretation, although I would say similar things about a book if I think it was bad.

If I buy a Ferrari that has a beautiful design and beautifully manufactured parts, but it is assembled poorly, am I saying the Ferrari is good or bad? I would say I am saying both - the Ferrari is in principle a great car, but the assembling has resulted in it being a bad car to drive.

So I think you're both right - Adam is right because he is saying this is a good book that has been let down because of all these errors, and you're right because you're saying Adam is effectively saying this is a bad book that should be avoided because all the errors have spoilt an otherwise good book!

This is an excellent observation. Certainly Jeanne and Scott put a big amount of effort to write this book and it is a great supplement, but some mistakes during cycle of writing a book lowered some of its quality. Nevertheless, this book is being very helpful (and this is why I still continue reading it).

[Ahmed Bin S]

I actually purchased the OCP book only last week, I have an SCJP 1.4 but have rarely used Java since, and as I want to get serious about developing Java web applications, I decided maybe it would be nice to first learn the new features thoroughly.

I must say, I am enjoying the book, which is good, otherwise I might as well be reading the JLS. I just hate frigging Kindle and wish a pdf version had been available for me to purchase...

[Roel De Nijs]

Adam Scheller wrote:Nevertheless, this book is being very helpful (and this is why I still continue reading it).

61 (and counting) Amazon reviewers can't be wrong

[Andrew Polansky]

I have missed Jeanne's response when I did my last post.

Jeanne, it is very nice that you take time to write in this thread. Thank you for the explanation how the reviewing process looked like. Sad errors slipped into the book, but as Roel said, thankfully those are not the ones being hard to spot even for a Java newbie. Your OCA book is still very helpful despite those mistakes, so I am sure that I will buy the OCP book as well.

[Jeanne Boyarsky]

Adam Scheller wrote:I have missed Jeanne's response when I did my last post.

I posted a whole 3 minutes before you . You were probably already typing when I posted it.

[Andrew Polansky]

Jeanne Boyarsky wrote:

Adam Scheller wrote:I have missed Jeanne's response when I did my last post.

I posted a whole 3 minutes before you . You were probably already typing when I posted it.

That's correct

[Scott Selikoff]

As Jeanne pointed out, all technical books are prone to errors, and ours is no different. You can see the 324 replies on this forum for Kathy/Bert's as an example.

One thing to keep in mind is that not all errata is equal. Some are big, some are small. Like when a word is missing from sentence that does not change the meaning in any way. Some are more conceptual, such as where we could have explained things in more detail. I also see some things reported in this forum with the subject of "Errata" that if you read the contents, turn out to be a misunderstanding on the part of the reader. In other words, not every topic in this forum with the word "Errata" in the title is actually errata!

One thing we separates our book apart (and Kathy/Bert's too) is that we very much welcome, appreciate, and encourage you to find and discuss errata! We really love it! If we could make the entire ranch our technical proofers we would. We also spend a great deal of time checking and cataloging, so that future editions will not contain the same errors.

Jeanne and I did spend a lot of time correcting errors in this book... you should have seen the ones that got fixed! One thing that complicated things this time around is Oracle changed the objectives numerous times causing us to reshuffle things. We wrote an entire appendix on Nashorn that became unused for the exam!

In short, keep up the excellent work, all of your feedback is welcome and considered!

[Scott Selikoff]

Oh, and I agree with Jeanne, you have to decide for yourself if the errata are dealbreakers. Despite errors in both of our books, people frequently post on Amazon and this forum that they were able to pass the exams with it.

I will say the OCP exam is much harder than the OCA exam, so make sure you really understand the material! Good luck!

[Andrew Polansky]

Thanks for your comments Scott. If you need a picky tech reviewer for your next book, send me PM