Full stack web dev.
Studying FP web development approaches, while helping Mission Bit create paths to programming for underserved public school kids.
Previously @ Gradescope.
Glad you eventually got some value out of it... as someone interested in the history of the field, I found the references to older tech to be a nice bonus back when I read it.
Much of the rest is timeless, though IIRC it applies more readily to very large teams writing very large projects from scratch while maintaining large typewritten manuals, and all of it without the benefit of VCS.
So much of what Brooks advocates for (and I don't mean to imply that he was the lone voice) has become conventional -- tracking milestones, avoiding complexity, prototyping, versioning, standardizing tools, separating spec from implementation -- that I doubt many folks reading MMM today would be surprised by any of the takeaways. But I found it interesting both as a primary source and as a window into a time when those practices couldn't be gotten for free or taken for granted.
Peopleware is another classic in this vein, but unlike MMM, its lessons (despite empirical proof) are often ignored.
And though I haven't yet, I'm looking forward to reading Patterns of Software at some point.
What he calls "self-documenting programs" we would today call "well-commented code".
I don't follow. Self-documenting code is code that reduces the need for explanation, including comments. As you mentioned, things like "show, don't tell" and "use the parts of the program that have to be there anyway" are what you want -- more specifically, they're preferable to comments, and part of an alternative.
I think you're right. Most of what is discussed in TMM is taken for granted nowadays -- lots of disk space so comments can be interleaved with source code, distributed version control systems, better communication across teams, and more.
Brooks actually recommends Peopleware near the end of TMM, so I'll definitely have to check it out.
Finally, with regards to your last comment, I think it's a matter of usage. From what I can gather from Brooks' writing in TMM, he defines "self-documenting programs" as programs which have the documentation included with the source code, as opposed to typed up and printed in a separate manual somewhere. I think I agree with your more modern definition of "self-documenting code", in that variable names, function names, etc. should be self-explanatory, and therefore not need much documentation or commenting at all. I think it's just a shift in the connotation since 1975.
Full stack web dev.
Studying FP web development approaches, while helping Mission Bit create paths to programming for underserved public school kids.
Previously @ Gradescope.
Glad you eventually got some value out of it... as someone interested in the history of the field, I found the references to older tech to be a nice bonus back when I read it.
Much of the rest is timeless, though IIRC it applies more readily to very large teams writing very large projects from scratch while maintaining large typewritten manuals, and all of it without the benefit of VCS.
So much of what Brooks advocates for (and I don't mean to imply that he was the lone voice) has become conventional -- tracking milestones, avoiding complexity, prototyping, versioning, standardizing tools, separating spec from implementation -- that I doubt many folks reading MMM today would be surprised by any of the takeaways. But I found it interesting both as a primary source and as a window into a time when those practices couldn't be gotten for free or taken for granted.
Peopleware is another classic in this vein, but unlike MMM, its lessons (despite empirical proof) are often ignored.
And though I haven't yet, I'm looking forward to reading Patterns of Software at some point.
I don't follow. Self-documenting code is code that reduces the need for explanation, including comments. As you mentioned, things like "show, don't tell" and "use the parts of the program that have to be there anyway" are what you want -- more specifically, they're preferable to comments, and part of an alternative.
I think you're right. Most of what is discussed in TMM is taken for granted nowadays -- lots of disk space so comments can be interleaved with source code, distributed version control systems, better communication across teams, and more.
Brooks actually recommends Peopleware near the end of TMM, so I'll definitely have to check it out.
Finally, with regards to your last comment, I think it's a matter of usage. From what I can gather from Brooks' writing in TMM, he defines "self-documenting programs" as programs which have the documentation included with the source code, as opposed to typed up and printed in a separate manual somewhere. I think I agree with your more modern definition of "self-documenting code", in that variable names, function names, etc. should be self-explanatory, and therefore not need much documentation or commenting at all. I think it's just a shift in the connotation since 1975.
Oops, I misread you & thought you were advocating for a shift in the recommendation. But that makes perfect sense.