12 ms·
Books I recommend to my software engineering students
- downerending 6y ago> [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 6y agoI'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"
- downerending 6y agoThe difference is that in software, if you add a body and as in most organizations, that body has to appear useful, they will tramp about in the soup, making a big mess and harming progress. Unlike in war, the marginal curve of adding an extra body goes negative in software. And right quick unless circumstances are favorable. (If you doubt this, imagine a thousand Arthurs charged with implementing a CRUD app.)
- bcrosby95 6y agoFrom 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 6y agoThat's a good summary. My years suggest that he wasn't nearly pessimistic enough.
- ggm 6y agoYou mean if you add 9 women you get a baby in 81 months?
- downerending 6y agoI 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 6y ago100% 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!
- ggm 6y agoI should say that I mis-speak (write) characterising MMM this way, its how its casually talked about. The incremental benefit of adding people can be higher than zero, but less than enough to be worth the cost. It can also be negative which is the core point MMM was making. Can be, is not always. And of course there are problems where it simply cannot alter the trajectory at all (the baby problem)
- epdlxjmonad 6y agoReading this book AND trying to follow its key lessons makes a huge difference in productivity, which I can testify from my own experience. This book is often compared to the bible of software engineering, suggesting that everyone knows about the book (ex: 'no silver bullet'), some people read it, but only few people abide by it. So, its key lessons are hard to follow in the real world, but for a good reason. We started a project 5 years ago, after a few months of failed attempts. From the very onset of the project, we tried to adhere to the key lessons of the book. Examples are: recognizing the importance of minimizing communication overhead (the most important assets are not people but time), following the surgical model (key decisions should be made by a single individual), practicing effect-free programming whenever possible, allocating enough time for testing, and so on. I would definitely attribute the success of our project to the teachings of the MMM. Like many books on software engineering (and self-help books in general), just reading a book and learning its contents may not make any difference in practice. Only when you seriously make conscious efforts to practice its teachings do you realize what the book is really about. This is also the reason why many university courses on software engineering are boring.
- adamnemecek 6y agoThese 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 6y agoECS systems are great, but claiming they are the only option available is more than a tad unreasonable.
- tuckerconnelly 6y agoAs inflammatory and irrelevant as this comment is or seems to be, I'd have to agree ECS is, at least, underrated. My mind was blown when I learned about it.
- madhadron 6y agoCan someone explain to me what separates ECS from relational modeling in databases?
- _hardwaregeek 6y agoI'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 agoI 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 agoits shown in the main photo at the top of the article?
- pjmorris 6y ago'Becoming A Technical Leader', Gerald Weinberg
- Jtsummers 6y agoI 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...
- scaryclam 6y agoI'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 6y agoPeopleware is another good one.
- eralps 6y agoI'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
- ninetyfurr 6y agoClean Coder is great for developers just starting their career.
- symplee 6y agoI bought my boss two copies of The Mythical Man-Month so he could read it twice as fast.
- aswanson 6y agoGood one. I chuckled.
- deanmen 6y agoIf he keeps one copy at home and one copy at the office, he could get done reading faster than if he left a single copy in one place and only read it at that place.
- 361994752 6y agoAnd he hired 4 people to read to him for each book. Now he could learn 8 times as fast.
- lactobacillis 6y agoNot 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.
- dpeck 6y agoI've often had thoughts of opening up a little web shop that anonymously shipped copies of The Mythical Man-Month in bulk.
- no-s 6y agoI used to leave copies of Mythical Man Month on the seats of the MUNI in SF during the DotCom era. Also PeopleWare. Actually Patti Dunn gave me a few hundred extra copies of PeopleWare from some Barclays event I accidentally attended and I couldn't conveniently get them home on my bike, so that was a one-time event. I so enjoyed the pragmatism of Crockford's "Javascript: the good parts" that I gave it away for a while too. Sometimes I would print out great tracts like "big ball of mud" and leave them at appropriate places in SF. Eventually I realized I was either preaching to the converted or preaching to the wilderness. So I stopped. But you've inspired me to reconsider anonymous viral software evangelism, at least for a brief moment.
- tracer4201 6y agoIf they want to get started with ML, I recommend Hands On Machine Learning with Scikit Learn and Tensorflow.
- mav3rick 6y agoHey I have no background in ML. Would you still suggest it ? I do systems.
- tracer4201 6y agoYes
- colmvp 6y agoAurelien Geron is very good at explaining concepts and I thought it was a lot more approachable than say the canonical Deep Learning book.
- rando832 6y ago"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-selected-essays-richard-m-stallman-3rd-edition https://shop.fsf.org/books-docs/free-software-free-society-s...
- User23 6y agoA Discipline of Programming, by Edsger Dijkstra. "For lack of a bibliography, I offer neither explanation nor apology."
- ianmcgowan 6y agoSoftware 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_Style#Lessons https://en.wikipedia.org/wiki/The_Elements_of_Programming_St...
- xwdv 6y agoI 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 6y agoI'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 6y agoOutliers 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.
- ipnon 6y agoI 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 6y agoFunny, 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.
- ken 6y agoIt’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 6y agoWhat 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.
- scotch_drinker 6y agoBlech. 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.
- madhadron 6y agoYeah, I use Gladwell as a negative control on book lists as well, along with Jared Diamond.
- gen220 6y agoHarari would be upset to be excluded from this list. :)
- diehunde 6y agoYou went too far with Coelho. Might as well throw some osho's books in there too.
- crease 6y agoI'm genuinely curious why Gladwell is a negative control. The name sounds familiar but I don't know much about him
- ardy42 6y ago> I'm genuinely curious why Gladwell is a negative control. The name sounds familiar but I don't know much about him He's written a lot of bestselling pop social science books. IIRC, he's a good storyteller, but is criticized for cherry-picking stuff to create the impression that you've just learned something profound and counter-intuitive when maybe you actually haven't. Here's a review of one that makes that point: https://www.newstatesman.com/2013/10/malcolm-gladwell-backlash-pseudo-profundity https://www.newstatesman.com/2013/10/malcolm-gladwell-backla... Disclaimer, I actually enjoy his books.
- 6y ago
- xvilka 6y agoI 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 6y agoCan I dive straight into Antifragile without having read the author's previous books?
- rramadass 6y agoSure. Any references to concepts from earlier books can be easily googled and learnt. Most books nowadays are around 200/500 pages but the essence is contained in only 20/30 pages.
- raihansaputra 6y agoI 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.
- hackermailman 6y agoScroll 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.
- aazaa 6y agoI'm surprised to see nothing on negotiation there.
- signa11 6y agofwiw, i found John Ousterhout's "A Philosophy of Software Design" pretty good actually (despite having misgivings about it earlier)
- soundsop 6y agoMy list for all engineering students: Design of Everyday Things Founders at Work Antifragile
- ironman1478 6y agoI 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.
- actsofthecla 6y agoI 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.
- rpwelch 6y agoCreativity 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 6y agoI 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 6y agoMy 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.
- geekraver 6y ago“ Note: This book does seem to overgeneralize and oversimplify complex situations, but there are still good points.” describes everything by Malcolm Gladwell.