Ask HN: Is "Code Complete" by Steve McConnell still a recommended read?
This book is considered a classic but the latest edition was published almost 20 years ago. Is it still relevant? Does it still succeed in its stated goal of bridging the gap between research and commercial software development?
12 comments
I read it last year and I think it's still relevant.
I had planned to write on the topic. In his book, Steve McConnell advocates for PPP = Pseudocode Programming Process
Basically, he says you should outlines the structure of your code first, before writing your actual code.
IMHO this is even more relevant in the age of AI assisted programming. Pseudocode Programming Process is becoming Prompt Programming Process.
The process is the same, it's just the tooling around it that has evolved.
I had planned to write on the topic. In his book, Steve McConnell advocates for PPP = Pseudocode Programming Process
Basically, he says you should outlines the structure of your code first, before writing your actual code.
IMHO this is even more relevant in the age of AI assisted programming. Pseudocode Programming Process is becoming Prompt Programming Process.
The process is the same, it's just the tooling around it that has evolved.
It's good advise and has helped me a lot over my 32 years of writing code (you pretty much had to pseudocode when I started as assembly isn't exactly expressive, especially for a young kid).
in nearly all my 100- and 200-level programming classes 20+ years ago, we had to hand-in a pseudocode for our assignment before our assignment
It didn't have to be completely correct, but it did need to be directionally correct (or, at least illustrate a way of solving the problem, even if we ended-up doing it differently)
I poo-pooed those, and would only create my pseudocode after writing my program - I'd already "been programming" for close to a decade, so why go through the 'pointless exercise' (as I thought at the time) of designing a solution only to have to implement the solution?!
Then I left those intro classes and we started getting more-interesting assignments
All of a sudden, having a plan - even a very simple block diagram, or set of bullet points, etc - became vital to solving the problem
I don't know that I'd tell someone to fully pseudocode their solution before implementing something today ... but blocking it out, getting the high- and medium-level logic/parts drawn-out/written-down is most definitely vital to having a chance at a successful implementation
It didn't have to be completely correct, but it did need to be directionally correct (or, at least illustrate a way of solving the problem, even if we ended-up doing it differently)
I poo-pooed those, and would only create my pseudocode after writing my program - I'd already "been programming" for close to a decade, so why go through the 'pointless exercise' (as I thought at the time) of designing a solution only to have to implement the solution?!
Then I left those intro classes and we started getting more-interesting assignments
All of a sudden, having a plan - even a very simple block diagram, or set of bullet points, etc - became vital to solving the problem
I don't know that I'd tell someone to fully pseudocode their solution before implementing something today ... but blocking it out, getting the high- and medium-level logic/parts drawn-out/written-down is most definitely vital to having a chance at a successful implementation
Interesting. I always do that when programming something non trivial. I found it very helpful to sort the threads and clear my thoughts and capture what I don't know but I thought I knew.
I then keep the pseudo code as comments in code and go from there.
But I don't know others are doing the same. I'm a pretty mediocre programmer so I have to do it a lot.
I then keep the pseudo code as comments in code and go from there.
But I don't know others are doing the same. I'm a pretty mediocre programmer so I have to do it a lot.
This is why expressive programming languages matter. If your language is expressive enough, the sketch will be executable.
Expressive languages help, but for anything larger than a homework problem I would still sketch up the system elements and how they communicate on a piece of paper, then write the implementation in a high level pseudocode. My 2c.
Does anyone actually do this?
I have never seen people write pseudo code as part of the programming process.
Diagrams, comments, tests, stubs sure, but never really pseudo code.
I have never seen people write pseudo code as part of the programming process.
Diagrams, comments, tests, stubs sure, but never really pseudo code.
I do it regularly but it's always invisible if all you see is the resulting code.
I do it to structure my code, but I remove the comments as I implement it because I try to make it obvious in the code what's being done. You know, regular good programming, pick good names, keep the code reasonably short, add comments when needed, etc.
The same way you won't see the detailed outline of a writing once it has been written. Yet, the author likely started with an outline.
I do it to structure my code, but I remove the comments as I implement it because I try to make it obvious in the code what's being done. You know, regular good programming, pick good names, keep the code reasonably short, add comments when needed, etc.
The same way you won't see the detailed outline of a writing once it has been written. Yet, the author likely started with an outline.
Yes all the time, how else?
I mean if it's just a few lines, a change to existing code, etc, you can jump straight in with actual code.
But if it's a new object/module etc, start by writing some function names, and some rough structure within them, etc. All in IDE/editor. And I wouldn't call it pseudo-code, just a rough outline.
I mean if it's just a few lines, a change to existing code, etc, you can jump straight in with actual code.
But if it's a new object/module etc, start by writing some function names, and some rough structure within them, etc. All in IDE/editor. And I wouldn't call it pseudo-code, just a rough outline.
That's exactly my point.
An outline is a very different beast compared to pseudo code.
It's effectively the difference between operational semantics and denotational semantics.
An outline is a very different beast compared to pseudo code.
It's effectively the difference between operational semantics and denotational semantics.
I studied systems engineering and the first class about algorithms and data structures started using pseudocode, then Pascal. And they still do today.
Sometimes, for some confusing piece of functionality that I am developing, I would write pseudocode in a comment first to see whether it makes sense; and would use it as an outline for implementing the feature. I've found it useful. I've never read Code Complete though :-)
>Diagrams, comments, tests, stubs sure, but never really pseudo code.
Hate to break it to you ... but those are all forms of pseudocode (or verification of your process (which is nearly the same thing)) :)
Hate to break it to you ... but those are all forms of pseudocode (or verification of your process (which is nearly the same thing)) :)
Heck, I still use stuff I picked up from Writing Solid Code.
That book hasn’t aged as well, but it had some parts that are still quite relevant, today.
I always thought that Rapid Development was better than Code Complete.
I’ve probably read all of McConnell’s stuff (and I’ve taken a lot of Construx courses). At one time, I was quite the fanboi.
A lot of folks around here don’t seem to like him, which I find odd.
That book hasn’t aged as well, but it had some parts that are still quite relevant, today.
I always thought that Rapid Development was better than Code Complete.
I’ve probably read all of McConnell’s stuff (and I’ve taken a lot of Construx courses). At one time, I was quite the fanboi.
A lot of folks around here don’t seem to like him, which I find odd.
I liked /Rapid Development/ too. It misses out on things like the Unix philosophy and worse-is-better, which are sort of previous incarnations of the agile/lean stuff that is very popular today.
I would assume the author just hadn't had much exposure to those ideas so they weren't even considered for inclusion. (Besides, they tend to not be researched so actively because they don't leave as many paper trails.)
Other than that gripe, though, I learned a lot from it!
I would assume the author just hadn't had much exposure to those ideas so they weren't even considered for inclusion. (Besides, they tend to not be researched so actively because they don't leave as many paper trails.)
Other than that gripe, though, I learned a lot from it!
McConnell has never really been a fan of “purist” Agile.
Construx eventually developed a curriculum around a fairly “corporate-friendly” version of Scrum, that I never found that appealing.
The way I write code, these days, makes Agile look like Orthodox religion.
However, it’s highly dependent upon me, being who I am, and a lifetime of habit and personal process. It would probably not scale well.
McConnell has always been about introducing process, metrics, and rigor to software development. I don’t think he’d be thrilled with the way I do stuff.
WFM. YMMV.
Construx eventually developed a curriculum around a fairly “corporate-friendly” version of Scrum, that I never found that appealing.
The way I write code, these days, makes Agile look like Orthodox religion.
However, it’s highly dependent upon me, being who I am, and a lifetime of habit and personal process. It would probably not scale well.
McConnell has always been about introducing process, metrics, and rigor to software development. I don’t think he’d be thrilled with the way I do stuff.
WFM. YMMV.
I don't expect him to like it, just mention it in any way whatsoever!
RAD was written in 1996
"Agile Development" (under that name, at least) didn't really appear on the scene til nearly the end of the decade
Precursors to it were there (spiral development, pair programming, etc) ... but kinda hard to write about something that didn't exist yet :)
"Agile Development" (under that name, at least) didn't really appear on the scene til nearly the end of the decade
Precursors to it were there (spiral development, pair programming, etc) ... but kinda hard to write about something that didn't exist yet :)
Well, Rapid Development is the next level after Code Complete :)
Code Complete is the "Introductory Level" and Rapid Development is the "Practitioner Level".
Code Complete is the "Introductory Level" and Rapid Development is the "Practitioner Level".
I think anything that makes you take a new perspective on (software) product development and reflect on your experiences and pay attention to patterns of outcomes is going to make you a better developer.
Even if the book would be hopelessly outdated, that's usually informative too. It tells you which specific parts of the industry change slowly and which evolve rapidly. That will help you figure out where we are headed and what you can count on will be roughly the same for the next 25 years of your career.
It's very hard to rank books precisely, because how much people get out of them also depends on past experiences.
If you already have the book or can get free access to it -- why not try? Even just the preview on Amazon is usually good to give a sense of what it is like. Read a few chapters and see if it's something you think you want to continue with.
But what's important is not that you pick The Right Book now, it's that you pick up another book when you are finished with this one.
Even if the book would be hopelessly outdated, that's usually informative too. It tells you which specific parts of the industry change slowly and which evolve rapidly. That will help you figure out where we are headed and what you can count on will be roughly the same for the next 25 years of your career.
It's very hard to rank books precisely, because how much people get out of them also depends on past experiences.
If you already have the book or can get free access to it -- why not try? Even just the preview on Amazon is usually good to give a sense of what it is like. Read a few chapters and see if it's something you think you want to continue with.
But what's important is not that you pick The Right Book now, it's that you pick up another book when you are finished with this one.
It's absolutely still relevant, but it might not be as dominant as it was when first released. By that I mean that the landscape of software development has changed significantly with much more community-driven ecosystems (no longer ~just CPAN) and much more programming is figuring out how to think about choosing the right off-the-shelf architectural components.
So, it's relevant and still excellent in guiding you how to write and manage code, but make sure you don't let it lead you to a conclusion that you should write your own code for all aspects of your system.
So, it's relevant and still excellent in guiding you how to write and manage code, but make sure you don't let it lead you to a conclusion that you should write your own code for all aspects of your system.
I'd say it's still a good resource to have; it's not just about programming but about project management, planning, etc.
I'd take their recommendations about code style and documentation and whatnot with a grain of salt though, languages, tools and styles have changed since then. Don't skip them, but don't adhere to them religiously; add them to your arsenal of knowledge.
It's also a bit of a slog to read front to back, so consider picking one chapter at a time or only looking up a subject you're curious about; I'd consider it more of a reference.
I'd take their recommendations about code style and documentation and whatnot with a grain of salt though, languages, tools and styles have changed since then. Don't skip them, but don't adhere to them religiously; add them to your arsenal of knowledge.
It's also a bit of a slog to read front to back, so consider picking one chapter at a time or only looking up a subject you're curious about; I'd consider it more of a reference.
> I'd take their recommendations about code style ... with a grain of salt though
IIRC, this book started me on the "meta-rules" of code style, the "what makes good rules", specifically
* aim for readability
* the role that "mere familiarity" plays in readability
* Team style over individual style, org over team, industry over org.
* the small amount (but not zero) of actual data i.e. studies here.
IIRC, this book started me on the "meta-rules" of code style, the "what makes good rules", specifically
* aim for readability
* the role that "mere familiarity" plays in readability
* Team style over individual style, org over team, industry over org.
* the small amount (but not zero) of actual data i.e. studies here.
It's in the same group as Pragmatic Programmer, Refactoring, Patterns of Application Architecture and the Gang-of-Four book for me. Still recommended for junior programmers as they're all teaching the core of good design.
However seeing as the better frameworks/languages/IDEs have internalised a lot of the learnings and that the specific conventions may be outdated - so just follow the recommendations for your platform/framework.
However seeing as the better frameworks/languages/IDEs have internalised a lot of the learnings and that the specific conventions may be outdated - so just follow the recommendations for your platform/framework.
I feel like understanding why a framework does things in some way makes it easier to wrap my head around it.
There's a book about modernizing PHP applications that when you read it you feel you are reading about symfony's architecture.
There's a book about modernizing PHP applications that when you read it you feel you are reading about symfony's architecture.
In my opinion, it's as much a "recommended read" as a lot of other so-called "classics":
- Rapid Application Development (also by McConnell)
- Soul of a New Machine by Kidder
- Mythical Man Month by Fred Brooks
- Programming Pearls by John Bentley
- Applied Cryptography (2e) by Bruce Schneier
- The Cuckoo's Egg by Cliff Stohl
- Structured Computer Organization by Tanenbaum & Todd
- Design Patterns: Elements of Reusable Object-Oriented Software by Gamma, Helm, etc
- A New Kind of Science by Wolfram
And many more could be added to this list
Sure, some of them use acronyms or reference technology that you've either never heard of or has been supplanted
But you could [nearly] do a find-and-replace on those "outdated" terms with a "current" term, and the books would [effectively] be up-to-date
Don't get hung-up on specific examples - they're just there to illustrate the problem domain
- Rapid Application Development (also by McConnell)
- Soul of a New Machine by Kidder
- Mythical Man Month by Fred Brooks
- Programming Pearls by John Bentley
- Applied Cryptography (2e) by Bruce Schneier
- The Cuckoo's Egg by Cliff Stohl
- Structured Computer Organization by Tanenbaum & Todd
- Design Patterns: Elements of Reusable Object-Oriented Software by Gamma, Helm, etc
- A New Kind of Science by Wolfram
And many more could be added to this list
Sure, some of them use acronyms or reference technology that you've either never heard of or has been supplanted
But you could [nearly] do a find-and-replace on those "outdated" terms with a "current" term, and the books would [effectively] be up-to-date
Don't get hung-up on specific examples - they're just there to illustrate the problem domain
I would still recommend it. Well actually I would recommend Code Complete II as it is the be updated version. I met Steve McConnell in person and have read most of his books. I've found them to be gems.
There is a lot of value in reading different things even if you aren't sure about the value to see what you pick up. Sometimes you will learn something or see a situation you never would have expected.
There is a lot of value in reading different things even if you aren't sure about the value to see what you pick up. Sometimes you will learn something or see a situation you never would have expected.
Regarding coding practices:
I work as a data engineer and I always wanted to enforce some rules for the team:
1. DAGs must have a section that describes what it does and have link to jira ticket and documentation if applicable. Stakeholders should be named too.
2. DAGs must have a created by and modified by section with a summary of what they did. Yes we can track changes in GitHub but if we do a lift and shift upgrade of Composer instances all trackable changes are gone.
3. Comment the sql queries wherever hacky. There is no way I know why the original author put up some conversions in the code.
4. Every etl should check source data before and check loaded data after. Put up some test cases there. For critical processes, failure should always trigger emails and slack message sent to at least two places: DE team and related stakeholder team. God there are SO MANY cases we can get rid the trouble to pick and clean the data because we did not reject obviously wrong source data.
5. Think about potential errors. If you have to SUM a column of large integers, watch for overflows. If your column is nullable, watch for unexpected nulls. Such and such.
I work as a data engineer and I always wanted to enforce some rules for the team:
1. DAGs must have a section that describes what it does and have link to jira ticket and documentation if applicable. Stakeholders should be named too.
2. DAGs must have a created by and modified by section with a summary of what they did. Yes we can track changes in GitHub but if we do a lift and shift upgrade of Composer instances all trackable changes are gone.
3. Comment the sql queries wherever hacky. There is no way I know why the original author put up some conversions in the code.
4. Every etl should check source data before and check loaded data after. Put up some test cases there. For critical processes, failure should always trigger emails and slack message sent to at least two places: DE team and related stakeholder team. God there are SO MANY cases we can get rid the trouble to pick and clean the data because we did not reject obviously wrong source data.
5. Think about potential errors. If you have to SUM a column of large integers, watch for overflows. If your column is nullable, watch for unexpected nulls. Such and such.
Good coding practices don't change much, so yes it is still relevant.
"Clean code" does change a lot based on IDEs and programming language. For example, we don't use variable names like mIntScore anymore. And we're finding that Javadocs might add little value and go out of date.
Architecture can change quite a bit too - all the async webs make things difficult. Most of the bug reports we get on mobile are not test coverable. e.g. some jankiness when going back to a page, or something like liking a post three levels down and finding that your like was not registered when you go back towards the home screen. We had some bugs like an OS modding text animations, making the text invisible in very niche situations. Then you have combos of ltr and rtl languages and layouts. Adding test coverage can be 4x the effort of writing the code once with no tests, not to mention the architecture for test support making things exponentially more complex.
Maybe we have to rethink what complete code really means.
Architecture can change quite a bit too - all the async webs make things difficult. Most of the bug reports we get on mobile are not test coverable. e.g. some jankiness when going back to a page, or something like liking a post three levels down and finding that your like was not registered when you go back towards the home screen. We had some bugs like an OS modding text animations, making the text invisible in very niche situations. Then you have combos of ltr and rtl languages and layouts. Adding test coverage can be 4x the effort of writing the code once with no tests, not to mention the architecture for test support making things exponentially more complex.
Maybe we have to rethink what complete code really means.
The "Good practices^TM" is a giant bag of mix of good practices, "clean coders", software evangelists and architect's fantasies being collected over various technologies
Agree, but sometimes looking for recent books with the same underlying message is better than going through the classic.
I read the mythical man month recently and the examples often involving OS/360 development are brutally outdated. I couldn't relate and I had to force myself to finish.
I read the mythical man month recently and the examples often involving OS/360 development are brutally outdated. I couldn't relate and I had to force myself to finish.
I find it surprising that you thought Mythical Man Month was "brutally outdated"
Bentley's Programming Pearls, by that standard, is also "brutally outdated" - but the point of the book is not "how do I make this work in early 1980s technology"
The point of PP is "ask the right question"
The point of MMM is "add resources when necessary; be brutally minimalistic about how many resources are added"
Bentley's Programming Pearls, by that standard, is also "brutally outdated" - but the point of the book is not "how do I make this work in early 1980s technology"
The point of PP is "ask the right question"
The point of MMM is "add resources when necessary; be brutally minimalistic about how many resources are added"
I said the examples are brutally outdated, not the message. The book is filled with acronyms and names I didn’t know because they are 60 years old.
I’d rather read a 2023 version if I could.
I’d rather read a 2023 version if I could.
The acronyms and names are basically irrelevant to the point, though :)
If anything, having "outdated" acronyms and names may actually make the message stronger - because you don't need to be distracted by what they "are", you can just accept they exist[ed] :)
If anything, having "outdated" acronyms and names may actually make the message stronger - because you don't need to be distracted by what they "are", you can just accept they exist[ed] :)
I get that it is a classic but arguing that understanding less words and examples in a book makes the message stronger is a tough sell.
The Mythical Man Month is also super anti-feminist, which I wish people talked about more if they're going to recommend that book.
I don't remember that. But I read it a long time ago. Can you supply a quote to back this up?
I found this:
https://www.goodreads.com/review/show/1461289590
"A team of two, with one leader , is often the best use of minds. [Note God's plan for marriage.]'"
That is only sexist if he is saying that the man is naturally the leader. Did he say that?
"A team of two, with one leader , is often the best use of minds. [Note God's plan for marriage.]'"
That is only sexist if he is saying that the man is naturally the leader. Did he say that?
At the time, it must have been the straight reading, right?
That is quite an assumption. But I don't know the full context of the quote.
The author is only forwarding what the Bible says. So your beef is not with the author, but actually with all religions.
The book is at least a decade or two out of political fashion.
For thousands of years, certainly in European culture, the default human entity, when not specified, was masculine in gender. By which I mean grammatical gender, not the current politically vogue meaning of "gender."
We don't need to disregard thousands of years of knowledge because the authors were unaware of what would be PC in their future. That would be puerile. ("Childish," from the Latin word for "boy.")
For thousands of years, certainly in European culture, the default human entity, when not specified, was masculine in gender. By which I mean grammatical gender, not the current politically vogue meaning of "gender."
We don't need to disregard thousands of years of knowledge because the authors were unaware of what would be PC in their future. That would be puerile. ("Childish," from the Latin word for "boy.")
> "Childish," from the Latin word for "boy."
I think you mean "puerile", not "childish."
"Child" comes from Proto-Germanic. https://www.etymonline.com/word/child says "no certain cognates outside Germanic".
The Latin word for boy is "puer": "a boy, lad (typically between ages 7-14 but could be younger) (older than an infans but younger than an adulescens)" - https://en.wiktionary.org/wiki/puer#Noun_4 .
Puerile comes "from Latin puerilis "boyish; childish,"'- https://www.etymonline.com/word/puerile .
Grammatic gender doesn't always match natural gender even in the European languages. "Wīfman" means "woman" in Old English but is grammatically masculine. The Old English "mann" meant generally "person". https://en.wiktionary.org/wiki/mann#Old_English making "wīfmann" a female person and "wæpnedmann" a male person, though "wer" was the usual word for "adult male" (remaining in "weregild" and "werewolf").
In modern Swedish there is no masculine gender, and "man" can mean either "an adult male" or "a person". Consider "Hysterektomi ... kan också göras om man har cellförändringar eller cancer i livmodern." which in English is "A hysterectomy can also be done if one has cell changes or cancer in the uterus." (from https://www.1177.se/behandling--hjalpmedel/operationer/opera... ).
The Swedish "man" in that sentence translates directly as "one" in English, not "adult male", though usually in English we would write "you" as a sort of third-person pronoun, over the more formal "one" - https://en.wikipedia.org/wiki/You#Third_person_usage , even when we don't know if the reader has a uterus.
I think you mean "puerile", not "childish."
"Child" comes from Proto-Germanic. https://www.etymonline.com/word/child says "no certain cognates outside Germanic".
The Latin word for boy is "puer": "a boy, lad (typically between ages 7-14 but could be younger) (older than an infans but younger than an adulescens)" - https://en.wiktionary.org/wiki/puer#Noun_4 .
Puerile comes "from Latin puerilis "boyish; childish,"'- https://www.etymonline.com/word/puerile .
Grammatic gender doesn't always match natural gender even in the European languages. "Wīfman" means "woman" in Old English but is grammatically masculine. The Old English "mann" meant generally "person". https://en.wiktionary.org/wiki/mann#Old_English making "wīfmann" a female person and "wæpnedmann" a male person, though "wer" was the usual word for "adult male" (remaining in "weregild" and "werewolf").
In modern Swedish there is no masculine gender, and "man" can mean either "an adult male" or "a person". Consider "Hysterektomi ... kan också göras om man har cellförändringar eller cancer i livmodern." which in English is "A hysterectomy can also be done if one has cell changes or cancer in the uterus." (from https://www.1177.se/behandling--hjalpmedel/operationer/opera... ).
The Swedish "man" in that sentence translates directly as "one" in English, not "adult male", though usually in English we would write "you" as a sort of third-person pronoun, over the more formal "one" - https://en.wikipedia.org/wiki/You#Third_person_usage , even when we don't know if the reader has a uterus.
I don't have my copy with me so I can't supply an exact quote right now. The part that really stuck out was about companies relocating though. First, there was absolutely no possibility that women would be working, and iirc the primary reason that a company might not want to relocate was that a wife might complain her husband had to move, thus inconveniencing his boss. Something like this.
It is not.
It's been about ten years since I read it, but I don't remember anything particularly "anti-feminist" in it. Or anything political at all. I'm curious why you think so.
lmao
I think "anti-feminist" implies it expressses some opinion about the feminist movement, which it doesn't, to my recollection.
That said, it is somewhat sexist in its assumption that all programmers are men, which is not a surprise given when it was published. That lack of gender inclusivity is right there in the title. But it doesn't really take away from the value of the writing unless you're trying to be offended.
That said, it is somewhat sexist in its assumption that all programmers are men, which is not a surprise given when it was published. That lack of gender inclusivity is right there in the title. But it doesn't really take away from the value of the writing unless you're trying to be offended.
The book's nearly 50 years old. Most books not written very recently are not going to adhere to contemporary values and mores. If you're not willing to offer generosity when reading them and pick the useful part and discard the parts that haven't aged well, then you're going to miss out on a lot of very worthwhile reading.
That's one way to look at it. Another way to look at it is: Why do we not *update* these books? This gets back into the question of copyright of course.
Sensitivity Readers haven't been universally popular.
[edit] With Economist link: https://www.economist.com/britain/2023/03/23/editing-roald-d...
[edit] With Economist link: https://www.economist.com/britain/2023/03/23/editing-roald-d...
Because the human brain has the capacity to frame specific pieces of work in their time periods, understand the discrepancies between past and present and work around it.
I would also like to offer an additional counterpoint: Leaving work intact will, not only preserve the work "as is", but also contribute to future historians the true sociological impression that is aptly accurate for their time period.
I would also like to offer an additional counterpoint: Leaving work intact will, not only preserve the work "as is", but also contribute to future historians the true sociological impression that is aptly accurate for their time period.
Because then we lose any sense of historical context.
Old books at their essence lets us talk to people from the past. We won't always like what they have to say, but they will speak about themselves and highlight how we've changed. If we can't understand where we came from, then we can't hope to understand how we got where we are.
Old books at their essence lets us talk to people from the past. We won't always like what they have to say, but they will speak about themselves and highlight how we've changed. If we can't understand where we came from, then we can't hope to understand how we got where we are.
What? Tons of books get new editions. It happens constantly. For example, Strunk & White [0] has been updated in 1918, 1959, 1999, and 2009. Authors release different versions of their own books. I just wrote a review of a book [1] that had a 2nd edition released in 2022 after the first edition was released in 2014. J.R.R. Tolkein retconned The Hobbit after publication of Lord of the Rings. [2] (I realize this isn't really the same thing but I wanted to give an example in fiction)
Anyway, point is, tons of books are changed after publication. I don't see why The Mythical Man Month shouldn't be; the technology is out of date and the gender issues are out of date.
[0] https://en.wikipedia.org/wiki/The_Elements_of_Style
[1] https://www.amazon.com/Everybody-Writes-Improved-Go-Ridiculo...
[2] https://birthmoviesdeath.com/2012/12/13/how-jrr-tolkien-pull...
Anyway, point is, tons of books are changed after publication. I don't see why The Mythical Man Month shouldn't be; the technology is out of date and the gender issues are out of date.
[0] https://en.wikipedia.org/wiki/The_Elements_of_Style
[1] https://www.amazon.com/Everybody-Writes-Improved-Go-Ridiculo...
[2] https://birthmoviesdeath.com/2012/12/13/how-jrr-tolkien-pull...
Technical revisions, sure. At the same time books re-published to align with the political zeitgeist rarely tend to age particularly well.
I don't think there's much evidence to support your viewpoint.
Most books don't age well.
I tried to read Baum's "The Woggle-Bug Book" a few years ago, and found its humor, rooted in old ethnic stereotypes, totally un-enjoyable. It did not age well.
While the Hardy Boy books I enjoyed as a kid wouldn't have been so wildly popular had they kept the original text. ("From 1959 to 1973, the first 38 books were extensively revised, largely to remove depictions of racial stereotypes" says Wikipedia.)
One of the most popular Agatha Christie novels is "And Then There Were None". That was "re-published to align with the political zeitgeist" so much they even changed the title and the name of the island. Most people have read the re-aligned version, not the original version.
And as I learned recently, "Charlie and the Chocolate Factory" was "re-published to align with the political zeitgeist" in the 1970s, due to complaints by the NAACP and others that the Oompa-Loompas were African Pygmies. The re-write made them white, and the movie made them orange. The re-aligned version has outsold the original version.
Also in the 1970s, Geisel ("Dr. Seuss") edited "And to Think That I Saw It on Mulberry Street" to change how it describes and portrays a Chinese man. That book continues to be sold.
Carnegie's "How to Win Friends and Influence People" was revised in the 1981 edition to reflect the new feminist zeitgeist. For examples, "insurance man" was replaced with "insurance agent", and "leadership gravitates to the man who can talk" changed to "leadership gravitates to the person who can talk". It also dropped the section on marriage. ("Never get married until you have kissed the Blarney Stone. Praising a woman before marriage is a matter of inclination. But praising one after you marry her is a matter of necessity — and personal safety.") The preface to the 1981 edition points out how "Carnegie himself was a tireless reviser of his own work during his lifetime" and would have made changes because he was "sensitive to the changing currents of present-day life".
While not "tons of books", the fact that I - with little knowledge of book publishing history - can point to several counter-examples, suggests that there are a lot more popular books out there which were updated to the modern zeitgeist.
Most books don't age well.
I tried to read Baum's "The Woggle-Bug Book" a few years ago, and found its humor, rooted in old ethnic stereotypes, totally un-enjoyable. It did not age well.
While the Hardy Boy books I enjoyed as a kid wouldn't have been so wildly popular had they kept the original text. ("From 1959 to 1973, the first 38 books were extensively revised, largely to remove depictions of racial stereotypes" says Wikipedia.)
One of the most popular Agatha Christie novels is "And Then There Were None". That was "re-published to align with the political zeitgeist" so much they even changed the title and the name of the island. Most people have read the re-aligned version, not the original version.
And as I learned recently, "Charlie and the Chocolate Factory" was "re-published to align with the political zeitgeist" in the 1970s, due to complaints by the NAACP and others that the Oompa-Loompas were African Pygmies. The re-write made them white, and the movie made them orange. The re-aligned version has outsold the original version.
Also in the 1970s, Geisel ("Dr. Seuss") edited "And to Think That I Saw It on Mulberry Street" to change how it describes and portrays a Chinese man. That book continues to be sold.
Carnegie's "How to Win Friends and Influence People" was revised in the 1981 edition to reflect the new feminist zeitgeist. For examples, "insurance man" was replaced with "insurance agent", and "leadership gravitates to the man who can talk" changed to "leadership gravitates to the person who can talk". It also dropped the section on marriage. ("Never get married until you have kissed the Blarney Stone. Praising a woman before marriage is a matter of inclination. But praising one after you marry her is a matter of necessity — and personal safety.") The preface to the 1981 edition points out how "Carnegie himself was a tireless reviser of his own work during his lifetime" and would have made changes because he was "sensitive to the changing currents of present-day life".
While not "tons of books", the fact that I - with little knowledge of book publishing history - can point to several counter-examples, suggests that there are a lot more popular books out there which were updated to the modern zeitgeist.
Mike_12345(1)
I haven't read it, but what does it say about feminism?
Most likely no! Do you really need to read a 900 page book to understand how to write good code? There might be nuggets of wisdom here and there, but you'll most likely pick them on your own as you code and grow. Problem with these books is that you tend to over-apply whatever you read. You read the fact that configurations are good, so you create a nest of abstractions to make code configurable, even when it doesn't make sense. This is the stuff that I have seen happen over and over again. Over-engineered crap resulting from programmers trying to make future-proof code.
The best way is still, reading and writing lots of code. You'll pick the right way quite naturally.
The best way is still, reading and writing lots of code. You'll pick the right way quite naturally.
I agree that you don't need to have read it to be a good programmer. Yet, in my experience, there is a large overlap between those who are good programmers and those who have read it. With such a heavy use of anecdata, it's hard to say how much is causation or just correlation.
You have confused the book and its content with its application. One still needs to use their brain, and one blindly applying patterns from a book where it doesn't make sense doesn't make the book bad.
Have you read the book?
I'm not done, but many ideas I got from the book made me a better programmer.
I'm not done, but many ideas I got from the book made me a better programmer.
I know what you mean, but that's not really the fault of a book.