
Books I recommend to my software engineering students - ashort11
http://web.eecs.utk.edu/~azh/blog/booksformystudents.html
======
_hardwaregeek
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.

~~~
JamesBarney
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
Any books to recommend for the topics you mentioned? Especially sql or mongo.

~~~
pjmorris
I really liked 'The Art of SQL', Stephane Faroult

------
downerending
> [ _The Mythical Man-Month_ ] Key takeaway: You'll soon fall victim to the
> problems identified by this book, even after reading it.

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).

~~~
ggm
I've always like the MMM but there is also an undercurrent of this being a re-
telling of xeno's paradox, and its important to remember the rabbit actually
does win.

So, adding new bodies does incur cost, but the belief that always adding new
bodies always adds more cost than adds impetus to the outcome is not always
true.

The classic example is "the hump" which was the cost in fuel terms to ship
fuel to China, to be able to fly from China to bomb Japan. Economically
ruinous, people forget that missions were nonetheless successfully conducted:
it was ruinous but the outcome was achieved within limits.

So the MMM does not say "never add a body" it says "know what your incurring
in overhead, choosing to add a body"

~~~
bcrosby95
From what I recall, it talks about 3 somewhat related things.

First is that adding people slows things down in the short term.

The second is that due to overhead, adding people won't give linear speed up
in completion time.

And third, adding people won't help a project that is linear in nature. The
common example is using 9 women to get a baby in 1 month.

~~~
downerending
That's a good summary.

My years suggest that he wasn't nearly pessimistic enough.

~~~
ggm
You mean if you add 9 women you get a baby in 81 months?

~~~
downerending
I mean that in the limit, adding the n+c'th person isn't just useless, it's
devastating. If the optimal (in terms of calendar date of completion) size for
a project is (say) three people, it is entirely possible, if not almost
certain, that putting 30 people on the project will push the expected
completion date to infinity. In other words, the project will fail.

Now, you might say, "I will just bench those other 27 people" and have them
play cards or something. In most organizations, though, you _cannot do this_.
Instead, they must be _seen_ to be _useful_ somehow. And if you have 30 people
with their hands in a three-person project, no matter how peripherally,
failure is all but guaranteed.

I have seen this many times.

~~~
thr0w__4w4y
100% feel you.

Last time I worked at a big company, there was lots of dead wood, but one guy
in particular was just a massive liability. Nice guy, tried hard, but utterly
incompetent, and (I think there is a term for this?) he was unaware / ignorant
of how incompetent he was. He would often check in code that would break the
build (team of 300 engineers, large telecom system), he would write and run
scripts that would bring computing clusters to their knees (this was late 90s,
there are probably ways to mitigate that now), he would consume lots of high-
quality talent's time with basic questions, etc.

I literally asked my manager if we could pay Leo to sit home and play video
games. OF course, as you said, everyone's gotta look busy.

Here's the punchline: I learned a new term (to me, at the time... not sure
I've heard it again) from a greybeard/wizard there -- this guy was a genius.
He had a very appropriate term for Leo: negative producer.

Bingo!

------
xvilka
I would also recommend two more good books. They are relevant to almost every
aspect of life and creation process:

\- Antifragile: Things That Gain from Disorder by Nassim Nicholas Taleb[1]

\- Skunk Works: A Personal Memoir of My Years at Lockheed by Ben R. Rich[2]

[1]
[https://www.goodreads.com/book/show/13530973-antifragile](https://www.goodreads.com/book/show/13530973-antifragile)

[2]
[https://www.goodreads.com/book/show/101438.Skunk_Works](https://www.goodreads.com/book/show/101438.Skunk_Works)

~~~
cutty
Can I dive straight into Antifragile without having read the author's previous
books?

~~~
raihansaputra
I started from Antifragile and didn't regret it. If you feel like drawn toward
the earlier ideas, read Antifragile -> Skin In the Game -> Fooled By
Randomness -> Black Swan. This might also be related that I usually have more
interest in starting with practical knowledge and then digging deeper into the
theory/more basic knowledge.

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

~~~
jfim
Peopleware is another good one.

------
ianmcgowan
Software Tools by Kernighan and Plauger was the first programming book to blow
my mind, and changed the way I approach working in difficult/legacy systems.
As a programmer, you don't have to accept the limitations of the system you're
working with and by building simple tools can make even the worst system
bearable.

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.

[https://en.wikipedia.org/wiki/The_Elements_of_Programming_St...](https://en.wikipedia.org/wiki/The_Elements_of_Programming_Style#Lessons)

------
rando832
"The Design of Everyday Things", I would consider the digital versions to be

Code and Other Laws of Cyberspace

[http://codev2.cc/](http://codev2.cc/)

and

Free Software Free Society: Selected Essays of Richard M. Stallman

[https://shop.fsf.org/books-docs/free-software-free-
society-s...](https://shop.fsf.org/books-docs/free-software-free-society-
selected-essays-richard-m-stallman-3rd-edition)

------
eralps
I've read only the _The Mythical Man-Month_ from this list. It is amazing how
the project management really did not change much. Similar ideas (sometimes
same) to similar problems.

I would recommend watching this talk [0] from Kevlin Henney to anyone who
likes that book.

[0]: [https://youtu.be/AbgsfeGvg3E](https://youtu.be/AbgsfeGvg3E)

------
User23
A Discipline of Programming, by Edsger Dijkstra.

"For lack of a bibliography, I offer neither explanation nor apology."

------
actsofthecla
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, _Mythical Man Month_
and _GoF_ qualify as classics of software engineering. Or does the author mean
classics from the entirety of a CS program?

I've been teaching a software engineering class for a few years. Being
conscious of the high cost of textbooks, I find that _Applying UML and
Patterns_ by Larman achieves the best balance of practice, design, and
process.

For students who want to dig into agile methodologies I would recommend
_Extreme Programming Explained_ by Beck and the Poppendiecks on Lean.

In my opinion, a philosophical grounding is helpful for the programmer.
Accordingly, I'd want to suggest something like Locke's _Essay Concerning
Human Understanding_ or a secondary source on Aristotelian categories.
Moreover, a broad knowledge of different types of ethical systems will benefit
a developer.

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.

------
ipnon
I don'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.

Large software systems fail continuously in countless ways all the time.
Google search will still throw 404 or 5xx occasionally. We'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'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.

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 "best practices" ever will.

~~~
kaymanb
Funny, I'd say that writing proofs is a lot like building an airplane, and
software engineering might be far away from both.

In writing a proof, you provide an argument that justifies some claim is true.
Your argument has to be airtight, so that no matter what kind of counter
example or ugly scenario is proposed, your argument still holds.

The same seems true for an airplane. It needs to do its job (fly) and do so on
the face of a myriad of different external factors. If you build a plane, it
should "never" fail.

Software on the other hand, can be built without thinking about ALL of these
edge cases. Obvious it's better if it always works, but it's usually okay if
there is some bizarre scenario that causes an error. For some pieces of
software it might even be okay if these errors never get fixed (ie: a very
small number of users ever experience them). Software can work, even when it
(kinda) doesn't.

The Curry-Howard correspondence might be technically true, but we're just as
bad at writing specifications for programs as we are at writing the programs
themselves. It could be good to acknowledge that and just write the software
that solves most, but maybe not all, of our problems.

------
scotch_drinker
Blech. Nothing here that's obscure or likely to alter the path of some one's
knowledge. No philosophy, no history, and the list includes Gladwell.
Actually, the inclusion of Gladwell probably distinctly colors my thinking on
the subject.

Maybe "How to read a book" or "The Alchemist" or I don't know, something
that's not just so totally typical.

~~~
m11a
I personally don't like philosophy books. I think there's more to be learned
about philosophy by reading about specific topics, rather than actually
reading about philosophy. Some exceptions like Plato, etc.

Absolutely agree with history being useful, though. Any particular periods of
history you think are essential to know about, and any particular great books
on them?

~~~
gen220
I'm not the OP, but I agree that history's an essential subject.

History has many themes. These appear in every time and place, sometimes in
the forefront, sometimes in the background. I believe the most "essential"
period is the one that answers your questions.

So, I'd recommend picking any period that you have a vague curiosity for. I'd
go a half step further and recommend avoiding recent periods (late 20th
Century).

IMO, it's too recent for there to be consensus on what constitutes good
scholarship. There are obviously exceptions to this, but if you're new to
history reading, it's difficult to disambiguate the good from the bad.

Examples of periods and geographies that are particularly well-studied, with
good accessible literature:

\- Late antiquity in the mediterranean (fall of the roman empire)

\- Inter-war period in continental europe (Weimar, etc)

\- Revolutionary period in France, United States

\- Antebellum period in the United States

\- Early Russian Revolution (there aren't many good syntheses imo, because
this period was incredibly complicated)

\- Europe during the reign of Louis XIV (1643-1715)

\- Napoleonic wars and aftermath

This list is pretty euro-centric. IMO, these are the safest place to start, as
the plurality of english-language scholarship is in these places and periods.
After developing a good nose here, you'll feel comfortable reading in areas
where the scholarship isn't as deep.

------
rpwelch
Creativity Inc is a wonderful book, but Pixar'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 "The Phoenix Project"
to students.

~~~
Nezteb
I absolutely love The Phoenix Project, but it is 100% fiction and not based on
any real-world evidence. It’s great for laughs but I wouldn’t use it to
“teach” anyone.

~~~
m11a
My opinion: There's more we can learn from fiction than we think.

By analogy, creativity, perhaps even reality distortion. I don't think we
should solely rely on non-fiction and proven methods to teach or grow. Indeed,
if we did that, we wouldn't grow at all.

------
hackermailman
Scroll to the bottom of this page and watch the lectures on conceptual design
[https://stellar.mit.edu/S/course/6/fa18/6.170/materials.html](https://stellar.mit.edu/S/course/6/fa18/6.170/materials.html)
interesting analysis on why some software ideas fail on launch. He had a book
as well but the lectures are better so posted them.

------
ironman1478
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'd think all of it is fake or
exaggerated, but then you're living it and it's so depressing.

------
symplee
I bought my boss two copies of _The Mythical Man-Month_ so he could read it
twice as fast.

~~~
361994752
And he hired 4 people to read to him for each book. Now he could learn 8 times
as fast.

~~~
lactobacillis
Not if he outsourced the reading of said book to a foreign company. He would
would have to check if their reading was the same as his every hour for 18
months that would have taken him 3 days to read it himself. Slowly.

------
xwdv
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.

Outliers is kind of entrepreneurship junk food and 10,000 hours has already
been debunked.

~~~
LanceH
I'm not sure it's debunked and I don't understand the rabid hatred of it (like
bringing it up where it isn't mentioned at all).

~~~
madhadron
Outliers is debunked. The authors of the primary sources that he quoted
disavowed it as an inaccurate representation, and when you look outside of
kind learning environments like sports its becomes even less correct.

------
ken
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?

~~~
jdale27
What I took away from MMM was less concrete, actionable suggestions you can
implement, and more "things to watch out for" in the development process.
Things like the second system effect, and Brooks' Law (adding people to a late
project makes it later) are red flags. You can't always avoid them (management
will add warm bodies in desperation, you probably can't convince them
otherwise). But at least when you see second system effect happening you can
often try to mitigate it by design/architecture decisions.

I would also say the lessons around keeping teams small have been taken to
heart in industry somewhat, e.g. in the notion of the two-pizza team at
Amazon.

That said, some of Brooks' suggestions, such as the "surgical team" concept,
are more products of their era and haven't aged well.

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

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

~~~
mav3rick
Hey I have no background in ML. Would you still suggest it ? I do systems.

~~~
tracer4201
Yes

------
soundsop
My list for all engineering students:

Design of Everyday Things Founders at Work Antifragile

------
ninetyfurr
Clean Coder is great for developers just starting their career.

------
aazaa
I'm surprised to see nothing on negotiation there.

------
signa11
fwiw, i found John Ousterhout's "A Philosophy of Software Design" pretty good
actually (despite having misgivings about it earlier)

------
adamnemecek
These books will tell them nothing.

I legit think that there is only one way of engineering complicated software
and that is Entity-Component-System
([https://en.wikipedia.org/wiki/Entity_component_system](https://en.wikipedia.org/wiki/Entity_component_system)).

~~~
reificator
ECS systems are great, but claiming they are the only option available is more
than a tad unreasonable.

