On the preface to the 20th Anniversary Edition, he says something disappointing about our trade:

I was struck by how few of the propositions asserted in it have been critiqued, proven, or disproven by ongoing software engineering research and experience.

He also describes a very funny situation he lived in a plane:

The stranger sitting next to me was reading The Mythical Man-Month, and I was waiting to see if by word or sign he would react. Finally as we taxied towards the gate, I could wait no longer: “How is that book? Do you recommend it?” “Hmph! Nothing in it I didn’t know already.” I decided not to introduce myself. (p. 254)

As always, I need to quote 🗞️ How to read self-help:

But this is a hallmark of wisdom: it’s trivial to read but nearly impossible to put into practice (…) we need lots of examples to drive this wisdom home. We should be more forgiving of self-help (the genre) and more forgiving of ourselves. Putting wisdom into practice takes requxires reading, reflection, and practice.

Link to original

Also, another classic, 🦜 No matter how it looks at first, it’s always a people problem:

How can a book written 20 years ago [It’s going to be 50 years in 2025!] (…) still be relevant… (…) Hardware and software development, in contrast to manufacturing, remain inherently labor-intensive (…) The Mythical Man-Month is only incidentally about software but primarily abut how people in teams make things. (p. 254)

The title comes from one of the contained essays: “The Mythical Man-Month”, although probably the most popular essay ended up being: 📜 No Silver Bullet—Essence and Accident in Software Engineering.

“The Mythical Man-Month” expression refers to the wrongness of “man-month” measure when planning software:

Cost does indeed vary as the product of the number of men and the number of months. Progress does not. Hence the man-month as a unit for measuring the size of a job is a dangerous and deceptive myth. It implies that men and months are interchangeable. Men and months are interchangeable commodities only when a task can be partitioned among many workers with no communication among them (Fig. 2.1). This is true of reaping wheat or picking cotton; it is not even approximately true of systems programming. (…) The bearing of a child takes nine months, no matter how many women are involved (p. 16-17).

A consequence of this is the popular idea that “adding manpower to a late software project makes it later”, known as Brooks’s Law.

There are some very interesting essays in the book, such as: