8 ms·

I've advocated for a "canon" of books for software engineering and computer science that could be taught in school. The canon would accomplish several goals: it

I've advocated for a "canon" of books for software engineering and computer science that could be taught in school. The canon would accomplish several goals: it'd inform students about the less technical but profoundly important ideas within CS (Brooks' No Silver Bullet, The 10x cost incurred when moving from stage to stage in waterfall, how to treat and manage failure, etc.), it'd teach students how to think about problems (How To Solve It by Polya, The Design Of Everyday Things), and it'd provide history/culture (Coders At Work, Soul of A New Machine). One should, of course, learn how to program in a CS major. But there's diminishing returns on teaching programming in a class; ultimately students must make the shift from learning in class to teaching themselves. Perhaps teaching more of the "soft" aspects of CS would give better returns, especially as the students move up the ranks and start managing people.

pjmorris 6y ago
I agree with the idea of a canon for software engineering, probably more as a living, shifting document than as something set in stone (except, maybe, MMM, which seems perennial.) I'm going to try an experiment, posting five books I'd put on the list, one per comment. Downvote, upvote, add your own if you like the idea.
pjmorris 6y ago
'The Mythical Man Month', Fred Brooks
- FigmentEngine 6y ago
  its shown in the main photo at the top of the article?
pjmorris 6y ago
'Becoming A Technical Leader', Gerald Weinberg
- Jtsummers 6y ago
  I probably ought to read this one. I got on a Weinberg reading kick after reading some recommendations here a few months before his death. The one I particularly liked was The Psychology of Computer Programming. While dated in many ways (like MMM), it has a lot of interesting ideas and discussion about the structure and behavior of people and teams (regardless of discipline, though he was writing about programmers). I actually have a quote that I've kept in my office IM for a while that is a paraphrasing of Fisher's Fundamental Theorem [0]: Fisher's Fundamental Theorem states—in terms appropriate to the present context—that the better adapted a system is to a particular environment, the less adaptable it is to new environments. The theme of that quote kept coming up, I presume deliberately, in many of the later chapters. [0] https://en.wikipedia.org/wiki/Fisher%27s_fundamental_theorem_of_natural_selection https://en.wikipedia.org/wiki/Fisher%27s_fundamental_theorem...
  - gmassman 6y ago
    Isn't that why most people use Docker nowadays?
  - pjmorris 6y ago
    You might also find Weinberg's 'An Introduction To General Systems Thinking' of value. Weinberg was heavily influenced by general systems theory, as illustrated by referencing Fisher, and he wrote the book as a way to introduce others to that line of thinking.
pjmorris 6y ago
'The Pragmatic Programmer', Hunt and Thomas
pjmorris 6y ago
'Making Things Happen', Scott Berkun
pjmorris 6y ago
'Code Complete', Steve McConnell
- derangedHorse 6y ago
  I would recommend Clean Code over this one. Code Complete isn’t bad, but I feel like it’s filled with things most junior programmers already know
voicedYoda 6y ago
Design Patterns by Gamma, Helm, Johnson, and Vlissides (aka GoF)
- crimsonalucard 6y ago
  I still don't understand why people worship this book. Contrary opinion here but I think this book is actually below average. I think it's good that it introduces the overall concept of Design patterns, but the book itself isn't really about the general concept of Design patterns. The book is focused on OOP techniques and tricks. It makes the assumption that OOP is the most general way to modularize things and think about computation and design. Additionally a lot of the "patterns" aren't actually good, they're actually really bad. Many of the patterns introduced by this book actually increase complexity of a program while giving only an illusory sense of increased modularity and reuse-ability.
  - rfrey 6y ago
    The book didn't introduce people to design patterns, it invented the concept within the discipline of software programming. Perhaps one needs to have been in industry before and after this book to appreciate how it introduced a common vocabulary, a mechanism for documenting and sharing experience, and a framework for thinking about common problems.
    - crimsonalucard 6y ago
      >The book didn't introduce people to design patterns, it invented the concept within the discipline of software programming. By introduced I mean, introduced to the world for the first time. Invented is debatable concept as in was math invented or discovered? I avoid that debate by using the word "introduced." >Perhaps one needs to have been in industry before and after this book to appreciate how it introduced a common vocabulary, a mechanism for documenting and sharing experience, and a framework for thinking about common problems. Humans invent vocabulary for everything that they do, giving patterns names is inevitable. I would hardly call it revolutionary. This book just gave the concept of naming patterns a meta name in itself: "Design patterns." I think it's good that this was given a name but its importance is largely exaggerated. Case in point: Other disciplines of programming don't use the term "Design patterns" or formal pattern names that frequently. In fact, technically, there are tons and tons of "Design patterns" in procedural programming, declarative programming and functional programming, yet experts in these respective fields don't feel the need to give these concepts over-inflated and complicated nomenclature. Take currying for example. Functional programmers don't call it the "Curry pattern" nor do they refer to it as a design pattern (even though it technically is). A name just arose naturally. No need to give the concept of naming concepts another word. To take the illustration even further, imagine driving techniques. Should I give the concept of naming driving techniques some name to exaggerate its importance? Perhaps I can, I'll call it: "Vehicular Translation patterns." And instead of talking about cars using regular English like a normal person I'll just communicate like this: "Execute the drift pattern in composition with the slide pattern and inverse throttle pattern to maneuver through that turn." Talking like this helps me sound smarter while obfuscating communication to the point where it can only be understood by a select few. The book design patterns introduced to the programming world what could potentially be done for driving as well. Needless to say, if it's pointless to do this for driving then does that mean it's pointless to do for programming? In my opinion the answer to that question is, "Yes." In short, use english for most concepts and name things only where it matters and as it comes naturally. No need to invent an entire discipline and inflate it with made up epistemology. I realize race car driving does have it's own nomenclature but it's not over used to the extent of design patterns nor did they feel the need to give the nomenclature it's own nomenclature (vehicle translation patterns, VTS theory for short)
endgame 6y ago
History and culture is under-taught and under-appreciated. Maybe students can have a big debate in their third year about whether or not worse really is better?
GrumpyYoungMan 6y ago
Definitely needs DeMarco and Lister's "Peopleware".
tjr 6y ago
Would suggest also The Inmates are Running the Asylum, and for history/culture, the Jargon File.
janee 6y ago
I always thought a history book dedicated to snippets of old code or software problems that has a story to tell could be interesting. E.g. explaining an interesting or significant software problem and it's surrounding environment from each decade for the last 7 or so decades.
billfruit 6y ago
I'm kind of bothered by a lack of rigour and science in general software engineering disciplines. The vast majority of decisions seems to be made subjectively that any objective criteria. Also industry is very bad at documenting it's processes and experiences to the community, most documents if any are available to the company internally only. Also detailed histories of the devdlopment of large and complex software needs to be written and studied, but I just don't see it happening.
- RMPR 6y ago
  At least for the written part there's the "Architecture of open source applications" series.
- afpx 6y ago
  I wish I had more time to do that. I work at a feature factory.
kohtatsu 6y ago
I'd like to plug Responsive Communication. It's available entirely online here http://www.ankn.uaf.edu/curriculum/AxeHandleAcademy/rc/50patterns.htm http://www.ankn.uaf.edu/curriculum/AxeHandleAcademy/rc/50pat... It was written in 1986 by the linguist Ron Scollon and his wife Suzie. I found a paper copy on a free-book shelf outside a thrift store, and consider myself blessed to have stumbled upon it.
deleted 6y ago
[deleted]
Tomis02 6y ago
> The 10x cost incurred when moving from stage to stage in waterfall This seems to be a common falsehood propagated by Agile consultants and swallowed whole by an industry that doesn't know any better. It doesn't look like the waterfall model was ever used on a significant scale; not as far as I remember, anyway. https://softwareengineering.stackexchange.com/a/139107 https://softwareengineering.stackexchange.com/a/139107
- jimbob45 6y ago
  Agreed. Pure waterfall has become a strawman for the Agile zealots. Realistically, Waterfall is used as one component of the overall design and implementation process.
- Jtsummers 6y ago
  The waterfall model is definitely used at scale in DOD projects. It is as horrifying as it sounds.
- commandlinefan 6y ago
  > It doesn't look like the waterfall model was ever used Well - yes, it was used, and still is: it's the default if you're not careful or if you don't think very hard or realistically, or are very naive. The confusion is that is was only given a name to disparage it: W. Winston Royce observed that the way most people managed software projects was completely unrealistic and didn't take into account changing requirements. He called it "waterfall" as a way to underscore how inflexible the default "write down all the requirements, then write down how long they're going to take, then do them in that amount of time" approach was. Unfortunately, most people who adopt what they refer to as "agile" processes are still stuck in that same mindset; they think that, by having daily standups, putting in JIRA tickets, and referring to every two weeks as a "sprint", they'll somehow meet the project manager's pipe dream of 100% predictable software development schedules.
  - Jtsummers 6y ago
    Royce didn't set it up to disparage it. He set up his idealized flow and then proceeded to add details that he believed were critical to making it work. In the end, what he proposes is what most people understand to be Waterfall but with some extra details: - Feedback loops (because problems or deficiencies will arise) - Involving the customer (because you don't want to spend 12-60 months building the wrong thing) - Build a prototype (good advice) - Document, document, document (he thinks 1500 pages is a good target) The only thing practitioners seem to have taken away is that last bullet. He still made a strong distinction in his model between analysis, design, and implementation. Though, to be fair, at the time "programmer" was more of a technician level and design often involved making detailed designs like flowcharts and such that could be more easily translated into code. These days, design and implementation are really tangled up, and the documentation is awful an non-actionable (I've been on those teams, it's nightmare inducing). People think prose can replace a diagram, so they fill out their 1500 page quota with lots of words but no clarity. The name came later, and was enshrined in a DOD standard by people who couldn't read past the first few pages. So they entirely missed the lessons learned he was trying to apply to it.
JamesBarney 6y ago
I disagree. I think books on software management and process are mostly lost on someone who hasn't been involved in the process. (Hell many of those books are lost on project managers) I think the most important subjects to teach students are javascript, css, & sql (or mongo). Before you teach a beginner wood worker the "Zen of wood" you teach them how to cut a piece of wood without sawing off a finger. The rest will come later.
- MamaJumba 6y ago
  Any books to recommend for the topics you mentioned? Especially sql or mongo.
  - pjmorris 6y ago
    I really liked 'The Art of SQL', Stephane Faroult
  - rendall 6y ago
    Mongo has a series of online courses
- _hardwaregeek 6y ago
  Interesting counterpoint. I kind of agree that these books will be lost on people (although I believe I got something out of them and I'm early into my career). But I'm also thinking of it as providing early exposure so that if the students need guidance later on, they know where to visit. Much as high school students find the classics boring, but upon revisiting them later in life, discover their brilliance. I agree that you should teach the practice. My ideal education would be co-ops combined with a reading course or two on the canon.
- pjmorris 6y ago
  > I think books on software management and process are mostly lost on someone who hasn't been involved in the process. I think that's true and fair. However, once some experience has been acquired, I believe it's helpful to evaluate whether it's good experience or bad experience. Comparisons against the literature can be helpful at that point. Case in point: I tried reading 'The Psychology of Computer Programming' in college, but it didn't make much sense to me. Coming to it 15 years later, I realize it'd have been the perfect companion to my first five years in industry, naming and describing problems I'd faced and solutions that only came through experience more painful than reading.
harimau777 6y ago
I'd add the "Elegance is not Optional" essay from the preface to The Art of Prolog.
- falsissime 6y ago
  You probably meant The Craft of Prolog by Richard O'Keefe. The preface of the Art of Prolog is about David H. D. Warren's recollections of his first encounters with Prolog.
  - harimau777 6y ago
    Good catch! Thanks for pointing that out!

pjmorris 6y ago

I agree with the idea of a canon for software engineering, probably more as a living, shifting document than as something set in stone (except, maybe, MMM, which seems perennial.) I'm going to try an experiment, posting five books I'd put on the list, one per comment. Downvote, upvote, add your own if you like the idea.

pjmorris 6y ago

'The Mythical Man Month', Fred Brooks

FigmentEngine 6y ago
its shown in the main photo at the top of the article?

pjmorris 6y ago

'Becoming A Technical Leader', Gerald Weinberg

Jtsummers 6y ago
I probably ought to read this one. I got on a Weinberg reading kick after reading some recommendations here a few months before his death. The one I particularly liked was The Psychology of Computer Programming. While dated in many ways (like MMM), it has a lot of interesting ideas and discussion about the structure and behavior of people and teams (regardless of discipline, though he was writing about programmers). I actually have a quote that I've kept in my office IM for a while that is a paraphrasing of Fisher's Fundamental Theorem [0]: Fisher's Fundamental Theorem states—in terms appropriate to the present context—that the better adapted a system is to a particular environment, the less adaptable it is to new environments. The theme of that quote kept coming up, I presume deliberately, in many of the later chapters. [0] https://en.wikipedia.org/wiki/Fisher%27s_fundamental_theorem_of_natural_selection https://en.wikipedia.org/wiki/Fisher%27s_fundamental_theorem...
- gmassman 6y ago
  Isn't that why most people use Docker nowadays?
- pjmorris 6y ago
  You might also find Weinberg's 'An Introduction To General Systems Thinking' of value. Weinberg was heavily influenced by general systems theory, as illustrated by referencing Fisher, and he wrote the book as a way to introduce others to that line of thinking.

pjmorris 6y ago

'The Pragmatic Programmer', Hunt and Thomas

pjmorris 6y ago

'Making Things Happen', Scott Berkun

pjmorris 6y ago

'Code Complete', Steve McConnell

derangedHorse 6y ago
I would recommend Clean Code over this one. Code Complete isn’t bad, but I feel like it’s filled with things most junior programmers already know

voicedYoda 6y ago

Design Patterns by Gamma, Helm, Johnson, and Vlissides (aka GoF)

crimsonalucard 6y ago
I still don't understand why people worship this book. Contrary opinion here but I think this book is actually below average. I think it's good that it introduces the overall concept of Design patterns, but the book itself isn't really about the general concept of Design patterns. The book is focused on OOP techniques and tricks. It makes the assumption that OOP is the most general way to modularize things and think about computation and design. Additionally a lot of the "patterns" aren't actually good, they're actually really bad. Many of the patterns introduced by this book actually increase complexity of a program while giving only an illusory sense of increased modularity and reuse-ability.
- rfrey 6y ago
  The book didn't introduce people to design patterns, it invented the concept within the discipline of software programming. Perhaps one needs to have been in industry before and after this book to appreciate how it introduced a common vocabulary, a mechanism for documenting and sharing experience, and a framework for thinking about common problems.
  - crimsonalucard 6y ago
    >The book didn't introduce people to design patterns, it invented the concept within the discipline of software programming. By introduced I mean, introduced to the world for the first time. Invented is debatable concept as in was math invented or discovered? I avoid that debate by using the word "introduced." >Perhaps one needs to have been in industry before and after this book to appreciate how it introduced a common vocabulary, a mechanism for documenting and sharing experience, and a framework for thinking about common problems. Humans invent vocabulary for everything that they do, giving patterns names is inevitable. I would hardly call it revolutionary. This book just gave the concept of naming patterns a meta name in itself: "Design patterns." I think it's good that this was given a name but its importance is largely exaggerated. Case in point: Other disciplines of programming don't use the term "Design patterns" or formal pattern names that frequently. In fact, technically, there are tons and tons of "Design patterns" in procedural programming, declarative programming and functional programming, yet experts in these respective fields don't feel the need to give these concepts over-inflated and complicated nomenclature. Take currying for example. Functional programmers don't call it the "Curry pattern" nor do they refer to it as a design pattern (even though it technically is). A name just arose naturally. No need to give the concept of naming concepts another word. To take the illustration even further, imagine driving techniques. Should I give the concept of naming driving techniques some name to exaggerate its importance? Perhaps I can, I'll call it: "Vehicular Translation patterns." And instead of talking about cars using regular English like a normal person I'll just communicate like this: "Execute the drift pattern in composition with the slide pattern and inverse throttle pattern to maneuver through that turn." Talking like this helps me sound smarter while obfuscating communication to the point where it can only be understood by a select few. The book design patterns introduced to the programming world what could potentially be done for driving as well. Needless to say, if it's pointless to do this for driving then does that mean it's pointless to do for programming? In my opinion the answer to that question is, "Yes." In short, use english for most concepts and name things only where it matters and as it comes naturally. No need to invent an entire discipline and inflate it with made up epistemology. I realize race car driving does have it's own nomenclature but it's not over used to the extent of design patterns nor did they feel the need to give the nomenclature it's own nomenclature (vehicle translation patterns, VTS theory for short)

endgame 6y ago

History and culture is under-taught and under-appreciated. Maybe students can have a big debate in their third year about whether or not worse really is better?

GrumpyYoungMan 6y ago

Definitely needs DeMarco and Lister's "Peopleware".

tjr 6y ago

Would suggest also The Inmates are Running the Asylum, and for history/culture, the Jargon File.

janee 6y ago

I always thought a history book dedicated to snippets of old code or software problems that has a story to tell could be interesting. E.g. explaining an interesting or significant software problem and it's surrounding environment from each decade for the last 7 or so decades.

billfruit 6y ago

I'm kind of bothered by a lack of rigour and science in general software engineering disciplines. The vast majority of decisions seems to be made subjectively that any objective criteria. Also industry is very bad at documenting it's processes and experiences to the community, most documents if any are available to the company internally only. Also detailed histories of the devdlopment of large and complex software needs to be written and studied, but I just don't see it happening.

RMPR 6y ago
At least for the written part there's the "Architecture of open source applications" series.
afpx 6y ago
I wish I had more time to do that. I work at a feature factory.

kohtatsu 6y ago

I'd like to plug Responsive Communication. It's available entirely online here http://www.ankn.uaf.edu/curriculum/AxeHandleAcademy/rc/50patterns.htm http://www.ankn.uaf.edu/curriculum/AxeHandleAcademy/rc/50pat... It was written in 1986 by the linguist Ron Scollon and his wife Suzie. I found a paper copy on a free-book shelf outside a thrift store, and consider myself blessed to have stumbled upon it.

deleted 6y ago

[deleted]

Tomis02 6y ago

> The 10x cost incurred when moving from stage to stage in waterfall This seems to be a common falsehood propagated by Agile consultants and swallowed whole by an industry that doesn't know any better. It doesn't look like the waterfall model was ever used on a significant scale; not as far as I remember, anyway. https://softwareengineering.stackexchange.com/a/139107 https://softwareengineering.stackexchange.com/a/139107

jimbob45 6y ago
Agreed. Pure waterfall has become a strawman for the Agile zealots. Realistically, Waterfall is used as one component of the overall design and implementation process.
Jtsummers 6y ago
The waterfall model is definitely used at scale in DOD projects. It is as horrifying as it sounds.
commandlinefan 6y ago
> It doesn't look like the waterfall model was ever used Well - yes, it was used, and still is: it's the default if you're not careful or if you don't think very hard or realistically, or are very naive. The confusion is that is was only given a name to disparage it: W. Winston Royce observed that the way most people managed software projects was completely unrealistic and didn't take into account changing requirements. He called it "waterfall" as a way to underscore how inflexible the default "write down all the requirements, then write down how long they're going to take, then do them in that amount of time" approach was. Unfortunately, most people who adopt what they refer to as "agile" processes are still stuck in that same mindset; they think that, by having daily standups, putting in JIRA tickets, and referring to every two weeks as a "sprint", they'll somehow meet the project manager's pipe dream of 100% predictable software development schedules.
- Jtsummers 6y ago
  Royce didn't set it up to disparage it. He set up his idealized flow and then proceeded to add details that he believed were critical to making it work. In the end, what he proposes is what most people understand to be Waterfall but with some extra details: - Feedback loops (because problems or deficiencies will arise) - Involving the customer (because you don't want to spend 12-60 months building the wrong thing) - Build a prototype (good advice) - Document, document, document (he thinks 1500 pages is a good target) The only thing practitioners seem to have taken away is that last bullet. He still made a strong distinction in his model between analysis, design, and implementation. Though, to be fair, at the time "programmer" was more of a technician level and design often involved making detailed designs like flowcharts and such that could be more easily translated into code. These days, design and implementation are really tangled up, and the documentation is awful an non-actionable (I've been on those teams, it's nightmare inducing). People think prose can replace a diagram, so they fill out their 1500 page quota with lots of words but no clarity. The name came later, and was enshrined in a DOD standard by people who couldn't read past the first few pages. So they entirely missed the lessons learned he was trying to apply to it.

JamesBarney 6y ago

I disagree. I think books on software management and process are mostly lost on someone who hasn't been involved in the process. (Hell many of those books are lost on project managers) I think the most important subjects to teach students are javascript, css, & sql (or mongo). Before you teach a beginner wood worker the "Zen of wood" you teach them how to cut a piece of wood without sawing off a finger. The rest will come later.

MamaJumba 6y ago
Any books to recommend for the topics you mentioned? Especially sql or mongo.
- pjmorris 6y ago
  I really liked 'The Art of SQL', Stephane Faroult
- rendall 6y ago
  Mongo has a series of online courses
_hardwaregeek 6y ago
Interesting counterpoint. I kind of agree that these books will be lost on people (although I believe I got something out of them and I'm early into my career). But I'm also thinking of it as providing early exposure so that if the students need guidance later on, they know where to visit. Much as high school students find the classics boring, but upon revisiting them later in life, discover their brilliance. I agree that you should teach the practice. My ideal education would be co-ops combined with a reading course or two on the canon.
pjmorris 6y ago
> I think books on software management and process are mostly lost on someone who hasn't been involved in the process. I think that's true and fair. However, once some experience has been acquired, I believe it's helpful to evaluate whether it's good experience or bad experience. Comparisons against the literature can be helpful at that point. Case in point: I tried reading 'The Psychology of Computer Programming' in college, but it didn't make much sense to me. Coming to it 15 years later, I realize it'd have been the perfect companion to my first five years in industry, naming and describing problems I'd faced and solutions that only came through experience more painful than reading.

harimau777 6y ago

I'd add the "Elegance is not Optional" essay from the preface to The Art of Prolog.

falsissime 6y ago
You probably meant The Craft of Prolog by Richard O'Keefe. The preface of the Art of Prolog is about David H. D. Warren's recollections of his first encounters with Prolog.
- harimau777 6y ago
  Good catch! Thanks for pointing that out!