Hacker News Reader

Comment by spekcular | Hacker News Reader

I read the entirety of a draft of this once, about a year ago, when I was bored one night. I don't want to be overly critical of someone's book, so let me just say that:

A) I don't understand why an entire elementary statistics pseudo-textbook is bolted on at the end, forming the entire back half of the text, and

B) the title interested me because it promised concrete information that would improve my own software development, and while I found many things in the first half of the book, I didn't find this.

View on HN

The "statistics textbook" part is especially confusing to me -- who is the audience for this, and why is it even here?

He mentions at the beginning of the probability chapter:

"Readers are assumed to have some basic notion of the concepts associated with probabilities, and to have encountered the idea of probability in the form of likelihood of an event occurring"

This doesn't give us any insight into what background is expected here -- do I need to have taken a measure theory based probability course? Or would a calculus-based course suffice? What about a course for non-STEM majors? The word "basic" means different things to different people, and is generally an anti-pattern in mathematical writing. It's meaningless at best, and gatekeeping at worst.

Then he launches into this downright strange rabbit hole about mental models. None of this discussion in this chapter feels properly motivated, the writing is disjointed, and it reads like an unedited, non-proofread stream of consciousness. In particular, the exposition gets too distracted by its own examples.

Don't get me wrong -- many of the paragraphs in isolation are interesting, but taken together it's excruciating to read. It's an impressive project overall, and certainly ambitious, but it falls down due to the writer's lack of empathy for the reader. I suspect the situation would be better if they reduced the scope of the project and kept the writing more focused.

> I don't understand why an entire elementary statistics pseudo-textbook is bolted on at the end, forming the entire back half of the text

It's quite difficult to talk about empirical software engineering without discussing methods, after all papers like [1] were deemed necessary 20 years ago and still the occasional meta-paper is published about correct design of experiments or analyses. As someone who worked in the field it doesn't seem particularly surprising to see some treatment - there are a handful of papers in my former subfield that are oft-cited because they describe a statistical procedure/experiment design consideration, but they also bundle the explanatory stats "for free".

I would hazard a guess that the intent of these chapters is to equip the reader with enough background that they could replicate or run some of the experiments in the book to try to specify findings/experiments to their own organisations. I'd follow that with an assumption that the author felt that chapter 13 needed background, and recursed until they'd finished writing a textbook.

[1] Kitchenham et al. "Preliminary guidelines for empirical research in software engineering" 2001: http://www.ehealthinformation.ca/wp-content/uploads/2014/07/...

Can you expand a bit on point B? What sort of things did you find in this book, and why were you not able to apply them to your own practice of software engineering?

Sure. Chapter 1 is titled "Human Cognition" and reads like notes to an introductory psychology textbook. This is not a bad thing (psychology is fun to read about), but I didn't find any practical guidance about building software.

Chapter 2 is "Cognitive Capitalism." Here, I find a lot of social and economic commentary, but again, no information that will actually assist me in writing software.

The same story plays out for basically every other chapter, until we hit the material about statistics in the second half.

Another way to say it is that the level of abstraction feels a bit off, resulting in the sense that the discussion is somewhat superficial and disconnected from practice. It's like someone wrote a book on gardening that begins with a 200 page discussion of cell biology.

> concrete information that would improve my own software development

That’s what I was looking for when I clicked the link here. Do you have any recommendations for that kind of stuff, evidence-based if possible?

I would suggest the Clean Code/Coder/Architecture series of Robert Martin.

Reply on news.ycombinator.com