Books I recommend to my software engineering students

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.

&gt; [<i>The Mythical Man-Month</i>] Key takeaway: You&#x27;ll soon fall victim to the problems identified by this book, even after reading it.<p>Yeah, that pretty much describes all of software development in one stroke. But you should read it anyway (if only to experience the feeling of someone predicting your future before (most of) you were born).

I would also recommend two more good books. They are relevant to almost every aspect of life and creation process:<p>- Antifragile: Things That Gain from Disorder by Nassim Nicholas Taleb[1]<p>- Skunk Works: A Personal Memoir of My Years at Lockheed by Ben R. Rich[2]<p>[1] <a href="https:&#x2F;&#x2F;www.goodreads.com&#x2F;book&#x2F;show&#x2F;13530973-antifragile" rel="nofollow">https:&#x2F;&#x2F;www.goodreads.com&#x2F;book&#x2F;show&#x2F;13530973-antifragile</a><p>[2] <a href="https:&#x2F;&#x2F;www.goodreads.com&#x2F;book&#x2F;show&#x2F;101438.Skunk_Works" rel="nofollow">https:&#x2F;&#x2F;www.goodreads.com&#x2F;book&#x2F;show&#x2F;101438.Skunk_Works</a>

I&#x27;m disappointed not to see the pragmatic programmer there. I would think that it&#x27;s great reading, not only for every software developer, but also for stakeholders and product managers.

Software Tools by Kernighan and Plauger was the first programming book to blow my mind, and changed the way I approach working in difficult&#x2F;legacy systems. As a programmer, you don&#x27;t have to accept the limitations of the system you&#x27;re working with and by building simple tools can make even the worst system bearable.<p>And of course The Elements of Programming Style is a classic.. The lessons seem like clichés now, but there was a time when things that seem obvious now were hotly debated.<p><a href="https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;The_Elements_of_Programming_Style#Lessons" rel="nofollow">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;The_Elements_of_Programming_St...</a>

&quot;The Design of Everyday Things&quot;, I would consider the digital versions to be<p>Code and Other Laws of Cyberspace<p><a href="http:&#x2F;&#x2F;codev2.cc&#x2F;" rel="nofollow">http:&#x2F;&#x2F;codev2.cc&#x2F;</a><p>and<p>Free Software Free Society: Selected Essays of Richard M. Stallman<p><a href="https:&#x2F;&#x2F;shop.fsf.org&#x2F;books-docs&#x2F;free-software-free-society-selected-essays-richard-m-stallman-3rd-edition" rel="nofollow">https:&#x2F;&#x2F;shop.fsf.org&#x2F;books-docs&#x2F;free-software-free-society-s...</a>

I&#x27;ve read only the <i>The Mythical Man-Month</i> from this list. It is amazing how the project management really did not change much. Similar ideas (sometimes same) to similar problems.<p>I would recommend watching this talk [0] from Kevlin Henney to anyone who likes that book.<p>[0]: <a href="https:&#x2F;&#x2F;youtu.be&#x2F;AbgsfeGvg3E" rel="nofollow">https:&#x2F;&#x2F;youtu.be&#x2F;AbgsfeGvg3E</a>

A Discipline of Programming, by Edsger Dijkstra.<p>&quot;For lack of a bibliography, I offer neither explanation nor apology.&quot;

I take it that the goal is to list books of general interest for the software engineering student. It is not clear what the author means by classic CS material, so it is hard to know what is excluded. Surely, <i>Mythical Man Month</i> and <i>GoF</i> qualify as classics of software engineering. Or does the author mean classics from the entirety of a CS program?<p>I&#x27;ve been teaching a software engineering class for a few years. Being conscious of the high cost of textbooks, I find that <i>Applying UML and Patterns</i> by Larman achieves the best balance of practice, design, and process.<p>For students who want to dig into agile methodologies I would recommend <i>Extreme Programming Explained</i> by Beck and the Poppendiecks on Lean.<p>In my opinion, a philosophical grounding is helpful for the programmer. Accordingly, I&#x27;d want to suggest something like Locke&#x27;s <i>Essay Concerning Human Understanding</i> or a secondary source on Aristotelian categories. Moreover, a broad knowledge of different types of ethical systems will benefit a developer.<p>Lastly, as a kind of curve ball, I would recommend any STEM student to work through an LSAT preparation book. Technologies will come and go, but, throughout a career, the problems a developer encounters will likely have dimensions that require general critical thinking.

I don&#x27;t think you can teach software engineering. Writing software is more like writing proofs than building airplanes. Take a formally verifiable language like Agda for example. Proofs are indistinguishable from programs in that language. The Curry-Howard correspondence shows this is true for program-proofs in general.<p>Large software systems fail continuously in countless ways all the time. Google search will still throw 404 or 5xx occasionally. We&#x27;re not building airplanes that either fly or crash (although even the software running airplanes is now increasingly fault tolerant). We are effectively getting from point A to B through a variety of logical operators, increasing the set of valid A through trial and error. We find an input that throws error, our theorem was faulty and we update our proof. A seemingly valid input can&#x27;t produce the results we want, we double check to make sure our proof is still valid. Dilettante engineers will begin to introduce unbound complexity at this point for making fixes without understanding root causes.<p>For the above reasons, we should abandon any attempt at comprehensive software engineering curriculum or canons. We are not architecting a skyscraper to be delegated to a construction company to be built one and done for all of time. We are continually exploring and staking out a specific problem space. Our greatest compass in these new journeys will always be foundational computer science. We must take the specific and make it general. Careful application of elementary data structures, algorithms and discrete analysis will move and has moved us continents further than any convention to &quot;best practices&quot; ever will.

Blech. Nothing here that&#x27;s obscure or likely to alter the path of some one&#x27;s knowledge. No philosophy, no history, and the list includes Gladwell. Actually, the inclusion of Gladwell probably distinctly colors my thinking on the subject.<p>Maybe &quot;How to read a book&quot; or &quot;The Alchemist&quot; or I don&#x27;t know, something that&#x27;s not just so totally typical.

Creativity Inc is a wonderful book, but Pixar&#x27;s culture and work environment are exceedingly rare if not entirely unique. For a more realistic, yet still useful example of corporate culture, I would recommend &quot;The Phoenix Project&quot; to students.

Scroll to the bottom of this page and watch the lectures on conceptual design <a href="https:&#x2F;&#x2F;stellar.mit.edu&#x2F;S&#x2F;course&#x2F;6&#x2F;fa18&#x2F;6.170&#x2F;materials.html" rel="nofollow">https:&#x2F;&#x2F;stellar.mit.edu&#x2F;S&#x2F;course&#x2F;6&#x2F;fa18&#x2F;6.170&#x2F;materials.html</a> interesting analysis on why some software ideas fail on launch. He had a book as well but the lectures are better so posted them.

I had a professor make us read Death March by Yourdon and Peopleware. Both were great, especially Death March. It helped me notice bad patterns at an employer and gave me the motivation to quit. Its also very well written and funny, but a bit too real at times. You&#x27;d think all of it is fake or exaggerated, but then you&#x27;re living it and it&#x27;s so depressing.

I bought my boss two copies of <i>The Mythical Man-Month</i> so he could read it twice as fast.

I would swap out Outliers for Dark Pools, which better highlights how a revolution driven by Software Engineering in its purest form looks like, and is still ongoing to this day.<p>Outliers is kind of entrepreneurship junk food and 10,000 hours has already been debunked.

It’s interesting to see “The Mythical Man-Month” in a list like this, since I’ve never once seen any team implement what it suggests. Is it meant only as a cautionary tale?

“ Note: This book does seem to overgeneralize and oversimplify complex situations, but there are still good points.” describes everything by Malcolm Gladwell.

If they want to get started with ML, I recommend Hands On Machine Learning with Scikit Learn and Tensorflow.

My list for all engineering students:<p>Design of Everyday Things Founders at Work Antifragile

Clean Coder is great for developers just starting their career.

I&#x27;m surprised to see nothing on negotiation there.

fwiw, i found John Ousterhout&#x27;s &quot;A Philosophy of Software Design&quot; pretty good actually (despite having misgivings about it earlier)

These books will tell them nothing.<p>I legit think that there is only one way of engineering complicated software and that is Entity-Component-System (<a href="https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Entity_component_system" rel="nofollow">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Entity_component_system</a>).