Live data from Hacker News

The Bluffers Guide to the Mythical Man Month

codemanship.wordpress.com

21–30 of 95 posts

Re: The Bluffers Guide to the Mythical Man Month

#21
post #3

This is a very shallow summary of the Mythical Man Month, and it leaves out at least one concept that the book is most (in)famous for: the '10 times programmer'. An excerpt: > In one of their studies, Sackman, Erikson, and Grant were measuring performances of a group of experienced programmers. Within just this group the ratios between best and worst performances averaged about 10:1 on productivity measurements and a…

Despite many attempts to ignore this reality, entire languages like Go were invented to try mitigate this disparity.

This is starkly opposed to how Go is marketed, especially here on HN.

Go was designed to maximise the number of 'any developers' that could join a project, i.e. 1x developers.

Re: The Bluffers Guide to the Mythical Man Month

#22

once, when complaining to a colleague about our workplace and their hiring and staffing idiosyncrasies, I quipped "I should give a copy of TMMM". My colleague, without missing a beat said "You should give him two copies so he can read it faster"

I'm not sure if reading the book would help. If the manager has a technical background (e.g., they have worked as developers before) then they already know the main point of the book. If the manager does not have a tech background, then there's little that the book can do for them.

Re: The Bluffers Guide to the Mythical Man Month

#23

This is nothing new. In 1913, Max Ringelmann measured the effort of individuals when working in a group. The results are impressive: https://gallica.bnf.fr/ark:/12148/bpt6k54409695.image.f14 A group of 8 persons provides the same amount of work as 4 individuals.

Yep, This is why small teams work best. It also helps in maintaining better overall "Conceptual Integrity".

Ringelmann effect - https://en.wikipedia.org/wiki/Ringelmann_effect

Social loafing - https://en.wikipedia.org/wiki/Social_loafing

Re: The Bluffers Guide to the Mythical Man Month

#24
post #21

Earlier quoted context omitted.

Despite many attempts to ignore this reality, entire languages like Go were invented to try mitigate this disparity.

This is starkly opposed to how Go is marketed, especially here on HN. Go was designed to maximise the number of 'any developers' that could join a project, i.e. 1x developers.

Isn't this exactly what op was saying?

Re: The Bluffers Guide to the Mythical Man Month

#25
post #22

once, when complaining to a colleague about our workplace and their hiring and staffing idiosyncrasies, I quipped "I should give a copy of TMMM". My colleague, without missing a beat said "You should give him two copies so he can read it faster"

I'm not sure if reading the book would help. If the manager has a technical background (e.g., they have worked as developers before) then they already know the main point of the book. If the manager does not have a tech background, then there's little that the book can do for them.

You believe every tech oriented person already knows everything there is in the book?

Re: The Bluffers Guide to the Mythical Man Month

#26
post #22

Earlier quoted context omitted.

I'm not sure if reading the book would help. If the manager has a technical background (e.g., they have worked as developers before) then they already know the main point of the book. If the manager does not have a tech background, then there's little that the book can do for them.

You believe every tech oriented person already knows everything there is in the book?

No, but most will at some point in their career hear about it in comment sections on HN and the like, or in many different forms hear the adage that adding more people to a project makes it later.

Re: The Bluffers Guide to the Mythical Man Month

#27
post #22

once, when complaining to a colleague about our workplace and their hiring and staffing idiosyncrasies, I quipped "I should give a copy of TMMM". My colleague, without missing a beat said "You should give him two copies so he can read it faster"

I'm not sure if reading the book would help. If the manager has a technical background (e.g., they have worked as developers before) then they already know the main point of the book. If the manager does not have a tech background, then there's little that the book can do for them.

So this book is... not for people with a tech background, AND not for people without a tech background? Should I put the cat in the box now?

Re: The Bluffers Guide to the Mythical Man Month

#28

Earlier quoted context omitted.

I think the problem is that Computer Engineering is still not an engrained concept in universities. Sure, there are courses where some concepts are taught, but it's difficult if not impossible to tailor your degree towards being a real engineer.

This is the thing. A degree is closed-ended. You build things that can be done within a deadline, and have been done within that deadline, by hundreds of groups before you. You study well known problems that are described in many ways in various sources. When you work, you work on building things that don't have a specific end goal, without a specific deadline, where the success criteria are also not purely academic.…

Then how do civil engineers get their degrees?

Re: The Bluffers Guide to the Mythical Man Month

#29

Earlier quoted context omitted.

You believe every tech oriented person already knows everything there is in the book?

No, but most will at some point in their career hear about it in comment sections on HN and the like, or in many different forms hear the adage that adding more people to a project makes it later.

Everyone experiences things daily without fully appreciating the patterns and insights that could be derived from it (would be exhausting if we did)

The book most definitely helps tech workers.

Re: The Bluffers Guide to the Mythical Man Month

#30
post #21

Earlier quoted context omitted.

This is starkly opposed to how Go is marketed, especially here on HN. Go was designed to maximise the number of 'any developers' that could join a project, i.e. 1x developers.

Isn't this exactly what op was saying?

Thank you. I had it backwards.
Post reply on HN