5 ms·

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'

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 an amazing 5:1 on program speed and space measurements! In short the $20,000/year programmer may well be 10 times as productive as the $10,000/year one. Brooks did mention some other really useful concepts that are still very valid today: 'No silver bullet' and 'The second-system effect'. These should have been mentioned as well.

intelVISA 3y ago
Despite many attempts to ignore this reality, entire languages like Go were invented to try mitigate this disparity.
- wavesbelow 3y ago
  I sympathize with your sentiment, but I don't think Go has anything to do with this. The disregard for the fact that some engineers are more productive than others originates from companies' processes and planning. Projects are usually estimated without considering who will be working on the project and individuals are compressed to person-weeks. I have experienced it myself and read texts describing this issue in the same terms[1]. It doesn't really help that Go was designed in such a company, but saying that it was designed to mitigate this disparity is saying that the best predictor of an engineer's productivity is the number of LOC cranked out. I don't think that is the case, neither in principle nor in Google particularly. Much better predictors of productivity are effective communication and conceptual integrity of the design, as the linked article points out. It doesn't really help that you use brilliant language if, 6 months in, you've realized you're building the wrong thing, or you build it in the wrong way. 1. https://danluu.com/people-matter https://danluu.com/people-matter
- mrkeen 3y ago
  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.
  - misja111 3y ago
    Isn't this exactly what op was saying?
    - mrkeen 3y ago
      Thank you. I had it backwards.
  - makapuf 3y ago
    I get the assomption that with go you will avoid 0.2 programmers and make everyone a 1x programmer. But for me, a 10x programmer can generate complex, well engineered systems with a reasonable structure, not by writing everything in low level, super hard code ? From the level a 10x programmer might operate I'm not sure the programming language would be that important ? Expressivity is nice and some languages are better than others, but from my experience you can write nice artifacts from plain tools?
    - mrkeen 3y ago
      > a 10x programmer can generate complex, well engineered systems with a reasonable structure, not by writing everything in low level, super hard code ? Yeah maybe, but I'm certainly not at that level. If a 10x programmer exposes foo() and bar() methods to me, I'll call foo().bar() and not realise I've made a mistake, or that I've violated some invariant that's only in his head, not in the low-level code itself.
- bigbillheck 3y ago
  Many things are invented to solve problems that don't actually exist.
- whstl 3y ago
  In the end, Go is indeed effective at making engineers avoid arcane and difficult code, but doing the "difficult" stuff that's not available in Go is definitely not how the most productive engineers are productive. IMO, someone making code that abuses special features to the point it is difficult for other members (including future members) of the team to read is the definition of a negative-X programmer. Unless they're working solo, of course. Also, like wavesbelow mentioned in his great comment, the "10x" doesn't come from coding prowess alone: it starts long before that, with the process and planning.
INGELRII 3y ago
I agree. Mythical Man Month is a book to read. It's clear, interesting, and has better writing than summaries. Many classics like this are so good because the author is among the first to observe new phenomena. They can write down what they have learned without cultural narratives that distort reality. The hardest lesson in the book is the chapter 11 "Plan to Throw One Away". I have never seen this not to be the case in large systems. You must design the system to be rewritten. Accepting this is still a taboo. > In most projects, the first system built is barely usable. It may be too slow, too big, awkward to use, or all three. There is no alternative but to start again, smarting but smarter, and build a redesigned version in which these problems are solved. The discard and redesign may be done in one lump, or it may be done piece-by-piece. But all large-system experience shows that it will be done.2 Where a new system concept or new technology is used, one has to build a system to throw away, for even the best planning is not so omniscient as to get it right the first time. >The management question, therefore, is not whether to build a pilot system and throw it away. You will do that. The only question is whether to plan in advance to build a throwaway, or to promise to deliver the throwaway to customers. Seen this way, the answer is much clearer. Delivering that throwaway to custom- ers buys time, but it does so only at the cost of agony for the user, distraction for the builders while they do the redesign, and a bad reputation for the product that the best redesign will find hard to live down. >Hence plan to throw one away; you will, anyhow.
- johnnyanmac 3y ago
  >The hardest lesson in the book is the chapter 11 "Plan to Throw One Away" On the contrary, aren't factors like Microservices and all the constant prototyping at large companies encompass this? I feel in some ways they may have embraced the principle too much, to the point where prod doesn't have a properly stable solution to support while they are re-writing an experimetal "improvement".
  - zdragnar 3y ago
    Part of the problem is you don't necessarily understand the problem domain very well when you're starting out. There are plenty of examples of microservice architecture failures due to incorrectly dividing services- either causing too much internal communication for performance acceptance criteria, or struggling with service coordination when performing changes that impact multiple relationships. You may well end up throwing away some or many of your early microservices as you grow and the company better understands what it wants to build. Or, you can take another approach (which i have witnessed first hand), throw it all away and go back to a regular, well designed monolith and getting very significant performance improvements by doing things like SQL joins and transactions instead of putting events in a message queue and paying network traffic penalties.
civilized 3y ago
Has anyone else started feeling the following? In the last year or so, reading a banal, superficial, and platitudinous summary of something has, for me, become inflected with this feeling that it was written by GPT. In the case of this article, there are little details that suggest it was written by a person, like randomly choosing to abbreviate the book to T-MMM. But still, it's started happening for me that an article can feel "GPT-ish".
- kwertyoowiyop 3y ago
  I’m just glad they read it.
strangattractor 3y ago
And by 20K/yr programmer he likely means more experienced. Programmers tend to interpret this 10X as rockstar extremely prolific code programmer. In my experience the 10X programmer doesn't do things that impede the group or has enough experience to reduce the solution space to something manageable. Writing code is only part of the equation. Getting to a solution that works well cuts the time and lays the ground work for iterations and improvements. People the spew code that generally works are not as helpful.

intelVISA 3y ago

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

wavesbelow 3y ago
I sympathize with your sentiment, but I don't think Go has anything to do with this. The disregard for the fact that some engineers are more productive than others originates from companies' processes and planning. Projects are usually estimated without considering who will be working on the project and individuals are compressed to person-weeks. I have experienced it myself and read texts describing this issue in the same terms[1]. It doesn't really help that Go was designed in such a company, but saying that it was designed to mitigate this disparity is saying that the best predictor of an engineer's productivity is the number of LOC cranked out. I don't think that is the case, neither in principle nor in Google particularly. Much better predictors of productivity are effective communication and conceptual integrity of the design, as the linked article points out. It doesn't really help that you use brilliant language if, 6 months in, you've realized you're building the wrong thing, or you build it in the wrong way. 1. https://danluu.com/people-matter https://danluu.com/people-matter
mrkeen 3y ago
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.
- misja111 3y ago
  Isn't this exactly what op was saying?
  - mrkeen 3y ago
    Thank you. I had it backwards.
- makapuf 3y ago
  I get the assomption that with go you will avoid 0.2 programmers and make everyone a 1x programmer. But for me, a 10x programmer can generate complex, well engineered systems with a reasonable structure, not by writing everything in low level, super hard code ? From the level a 10x programmer might operate I'm not sure the programming language would be that important ? Expressivity is nice and some languages are better than others, but from my experience you can write nice artifacts from plain tools?
  - mrkeen 3y ago
    > a 10x programmer can generate complex, well engineered systems with a reasonable structure, not by writing everything in low level, super hard code ? Yeah maybe, but I'm certainly not at that level. If a 10x programmer exposes foo() and bar() methods to me, I'll call foo().bar() and not realise I've made a mistake, or that I've violated some invariant that's only in his head, not in the low-level code itself.
bigbillheck 3y ago
Many things are invented to solve problems that don't actually exist.
whstl 3y ago
In the end, Go is indeed effective at making engineers avoid arcane and difficult code, but doing the "difficult" stuff that's not available in Go is definitely not how the most productive engineers are productive. IMO, someone making code that abuses special features to the point it is difficult for other members (including future members) of the team to read is the definition of a negative-X programmer. Unless they're working solo, of course. Also, like wavesbelow mentioned in his great comment, the "10x" doesn't come from coding prowess alone: it starts long before that, with the process and planning.

INGELRII 3y ago

I agree. Mythical Man Month is a book to read. It's clear, interesting, and has better writing than summaries. Many classics like this are so good because the author is among the first to observe new phenomena. They can write down what they have learned without cultural narratives that distort reality. The hardest lesson in the book is the chapter 11 "Plan to Throw One Away". I have never seen this not to be the case in large systems. You must design the system to be rewritten. Accepting this is still a taboo. > In most projects, the first system built is barely usable. It may be too slow, too big, awkward to use, or all three. There is no alternative but to start again, smarting but smarter, and build a redesigned version in which these problems are solved. The discard and redesign may be done in one lump, or it may be done piece-by-piece. But all large-system experience shows that it will be done.2 Where a new system concept or new technology is used, one has to build a system to throw away, for even the best planning is not so omniscient as to get it right the first time. >The management question, therefore, is not whether to build a pilot system and throw it away. You will do that. The only question is whether to plan in advance to build a throwaway, or to promise to deliver the throwaway to customers. Seen this way, the answer is much clearer. Delivering that throwaway to custom- ers buys time, but it does so only at the cost of agony for the user, distraction for the builders while they do the redesign, and a bad reputation for the product that the best redesign will find hard to live down. >Hence plan to throw one away; you will, anyhow.

johnnyanmac 3y ago
>The hardest lesson in the book is the chapter 11 "Plan to Throw One Away" On the contrary, aren't factors like Microservices and all the constant prototyping at large companies encompass this? I feel in some ways they may have embraced the principle too much, to the point where prod doesn't have a properly stable solution to support while they are re-writing an experimetal "improvement".
- zdragnar 3y ago
  Part of the problem is you don't necessarily understand the problem domain very well when you're starting out. There are plenty of examples of microservice architecture failures due to incorrectly dividing services- either causing too much internal communication for performance acceptance criteria, or struggling with service coordination when performing changes that impact multiple relationships. You may well end up throwing away some or many of your early microservices as you grow and the company better understands what it wants to build. Or, you can take another approach (which i have witnessed first hand), throw it all away and go back to a regular, well designed monolith and getting very significant performance improvements by doing things like SQL joins and transactions instead of putting events in a message queue and paying network traffic penalties.

civilized 3y ago

Has anyone else started feeling the following? In the last year or so, reading a banal, superficial, and platitudinous summary of something has, for me, become inflected with this feeling that it was written by GPT. In the case of this article, there are little details that suggest it was written by a person, like randomly choosing to abbreviate the book to T-MMM. But still, it's started happening for me that an article can feel "GPT-ish".

kwertyoowiyop 3y ago
I’m just glad they read it.

strangattractor 3y ago

And by 20K/yr programmer he likely means more experienced. Programmers tend to interpret this 10X as rockstar extremely prolific code programmer. In my experience the 10X programmer doesn't do things that impede the group or has enough experience to reduce the solution space to something manageable. Writing code is only part of the equation. Getting to a solution that works well cuts the time and lays the ground work for iterations and improvements. People the spew code that generally works are not as helpful.