Book · 1975
The Mythical Man-Month
by Frederick P. Brooks Jr.
Fred Brooks managed IBM's late-1960s OS/360 project, then wrote the book explaining why adding more programmers only made it later.
What does Reddit think of The Mythical Man-Month?
332 mentions over seven years, and most of it isn't review, it's shorthand. Someone needs an explanation for why adding two engineers didn't speed up a late release, and Mythical Man-Month is the answer that keeps getting posted. r/programming carries the bulk of it and treats Brooks's core claim, that tasks don't partition cleanly and communication overhead grows faster than headcount, as settled fact rather than opinion (↑365). One comment (↑374) pairs it with "correlation does not imply causation," as if the two belong in the same toolkit. Another (↑407) needles a different thread for not mentioning the book at all, calling the omission odd given how directly it applies. r/learnprogramming's classics list (↑674) puts it alongside Code Complete and The Pragmatic Programmer, the syllabus version of respect rather than an argument for it. Written in 1975 about a mainframe project, and still the reference nobody in these threads disputes.
Community feedback & reader fit
Themes
- · Brooks's Law as the go-to explanation for late-project team scaling
- · Citation more than commentary, most mentions are drive-by references
- · A fixture on r/learnprogramming's classics reading lists
- · Treated as settled fact rather than a debatable opinion
Common praise
- + r/programming cites the book's core argument as settled fact, not up for debate (↑365).
- + One commenter calls out an entire thread for missing the obvious Mythical Man-Month reference (↑407).
- + r/learnprogramming keeps it on the short list of classics next to Code Complete and The Pragmatic Programmer (↑674).
Common criticism
- − A big share of the mentions are the title dropped into a syllabus-style list, not an argument for reading it (↑674).
- − The book's central case study is a 1960s mainframe OS project, and no displayed excerpt argues its details still map onto sprint-based teams.
- − One comment invokes it defensively, pairing it with "correlation isn't causation" rather than engaging with what Brooks actually measured (↑374).
Who it's for
Cite it once and you'll understand why it keeps coming up whenever a manager asks why adding headcount won't save a late release, that's the entire r/programming use case (↑365, ↑374). Want the book itself rather than the two-sentence version people keep reposting? Most of this data won't help, nobody here quotes it at length. Managers get more out of it than the individual contributors doing the actual estimating, if you go by which subreddits carry the discussion. And if 1975 mainframe scheduling sounds too dated to bother with, the Reddit sample offers no rebuttal either.
Mentions over time
Which Reddit comments matter for The Mythical Man-Month?
The most relevant excerpts across the subreddits where this book is mentioned — opinionated, argued takes first, then top-upvoted mentions. Click through to read the full thread.
“"I believe the hard part of building software to be the specification, design, and testing of this conceptual construct, not the labor of representing it and testing the fidelity of the representation." \- Fred Brooks, No Silver Bullet, 1986
“Wordpress is NOT essential, and if you try to pursue that path too heavily you will limit your earning potential. Companies with enterprise products are *starving* for quality UI engineers who can follow best practices for software development to deliver stable, maintainable, and well-tested solut…
“What I would call the classics: * Design Patterns - Elements of Reusable Object-Oriented Software * Code Complete * Rapid Development * The Pragmatic Programmer * The Mythical Man-Month * Operating Systems Design and Implementation * Refactoring - Improving the Design of Existing Code * The Algorit…
“Here's the list, for anyone interested in just that: 1. The Pragmatic Programmer by David Thomas & Andrew Hunt (67% recommended) 2. Clean Code by Robert C. Martin (66% recommended) 3. Code Complete by Steve McConnell (42% recommended) 4. Refactoring by Martin Fowler (35% recommended) 5. Hea…
“At IBM in the 1960s, Brooks managed the System/360 and OS/360 projects, the backbone of the mainframe era. His experiences were captured in a series of seminal essays, later published in "The Mythical Man Month", a must-read for software engineers. Other books included "The Design of Design". He la…
“It's a bit odd to make a whole post on this and give not so much as a mention to Mythical Man-month which kinda nails this in much clearer terms.
“It is true that correlation does not imply causation. It is also true that twice as many devs will not produce a system twice as fast. This is the Mythical Man Month. But these two truths are mostly unrelated to eac…
“Mythical Man Month - which was written in 1974 about software development covers this in chapter 2. It boils down to a couple of things: * tasks are not perfectly partitionable so adding more people does not linearly increase output * ass you add more people, you increase the size of the network …
“The Mythical Man Month Interesting to see how little progress we've made in the area of project management over the decades.
“Everyone should read the mythical man month (but especially managers!). It is a very short read and is as relevant today as ever.
“> "The Mythical Man Month", a must-read for software engineers And seemingly a must-ignore for engineering managers everywhere. The knowledge is out there, when will we learn? RIP Brooks. You will live on through your work forever.
“You joke, but for those that don't know, there is a book called "The Mythical Man Month" that every manager who works in tech should read.
“You should read the "Mythical Man Month", which is of important historical and practical significance for any informed discussion on this topic. Link here
“A decade ago? There's a book - The Mythical Man Month - that explains why it's a bad idea, which was published in 1975, over 45 years ago!
“TCS is still in business because the people who should read The Mythical Man-Month don't read it.
Convinced? Pick up The Mythical Man-Month
Readers also mention
Books that share discussion threads with The Mythical Man-Month — counted from the comments, not curated.
Guides featuring The Mythical Man-Month
Ranked best-of lists and editorial guides where this book's tracked mentions place it.
The Mythical Man-Month — frequently asked
Is The Mythical Man-Month still relevant in 2026?+
Yes, per every displayed excerpt that engages with it substantively. r/programming (↑365) treats Brooks's central claim, that adding people to a late project makes it later because tasks don't partition cleanly, as unchallenged fact fifty years on. Nobody in this sample argues the mainframe-era setting dates the point; one comment (↑407) is annoyed a different thread ignored it entirely.
What is Brooks's Law, the idea Reddit keeps citing from The Mythical Man-Month?+
It's the claim, echoed almost verbatim on r/programming (↑365), that adding manpower to a late software project makes it later, because communication overhead grows faster than headcount and most tasks can't be split cleanly among more people. A separate comment (↑374) pairs it with "correlation isn't causation" as a companion caution against oversimplified scaling arguments.
Should I actually read The Mythical Man-Month or just know Brooks's Law?+
Depends what you want it for. If you just need the argument for a standup or a Slack thread, r/programming's shorthand (↑365, ↑374) covers it. If you want to see it argued at length, this data doesn't help much: the book turns up mostly in classics lists like r/learnprogramming's (↑674) rather than in comments that quote its actual chapters.
Is The Mythical Man-Month one of the essential programming classics on Reddit?+
By citation frequency, yes. r/learnprogramming's classics list (↑674) puts it next to Code Complete and The Pragmatic Programmer, and it gets name-checked across a dozen subreddits over seven years. But essential here means cited, not read aloud and argued over. It's the reference everyone reaches for, not the book people discuss chapter by chapter.