Software engineering books | Hacker News Reader

Software engineering books

software-engineering-books.com

294 pointscolin-dumitru99 comments

Code Complete has some of my favorite quotes on programming.

  “The visual and intellectual enjoyment of well-formatted code is a pleasure that few nonprogrammers can appreciate.  But programmers who take pride in their work derive great artistic satisfaction from polishing the visual structure of their code.”

  “…there is a psychological basis for writing programs in a conventional manner: programmers have strong expectations that other programmers will follow these discourse rules.  If the rules are violated, then the utility afforded by the expectations that programmers have built up over time is effectively nullified.”

  “The smaller part of the job of programming is writing a program so that the computer can read it; the larger part is writing it so that other humans can read it.”

  “The information contained in a program is denser than the information contained in most books.  Whereas you might read and understand a page of a book in a minute or two, most programmers can’t read and understand a naked program listing at anything close to that rate.  A program should give more organizational clues than a book, not fewer.”

Excellent quotes, and certainly inspired me to put Code Complete on the reading list.

Out of curiosity - how did these quotes come to mind/hand so quickly? What's your notetaking process look like? How do you keep it all organized?

I freely highlight and take notes in my books, but also, I keep a blog and a Medium :)

people always want to know a big secret that will unlock the second brain, when really we know the answer and the hard part is doing the thing day in and day out haha

I always liked the feeling of looking at a well-formatted piece of code. But discussions about formatting always ensued with coworkers.

Lately, I've been deriving immense satisfaction from pressing Ctrl+Shift+I inside VSCode, and having Prettier format absolutely everything, with its sensible default settings and no leeway for discussion. It feels good.

I'm in love of Black formatter for python code: it leaves almost no option for formatting preferences. Format on save and you are done. It clears mental cycles for the important problems and make formatting discussions a thing of the past.

Same, also isort. I don’t think about it anymore unless for some reason my file watcher isn’t running.

> “The visual and intellectual enjoyment of well-formatted code is a pleasure that few nonprogrammers can appreciate. But programmers who take pride in their work derive great artistic satisfaction from polishing the visual structure of their code.”

Except those who code in Whitespace.

https://en.wikipedia.org/wiki/Whitespace_(programming_langua...

Given that I know have to use clang-format, the 'intellectual enjoyment of well-formated code' is a thing of the past.

This isn't a criticism of clang-format, just that as it is now a tool which does the formatting, I focus on other things..

I see Amazon affiliate links but zero disclosure that the author is earning a commission from these recommendations.

Affiliate links aren't a problem in themselves, but it's misleading and unethical to recommend a product without disclosing your financial incentives to the reader.

If you're in the US, this is a violation of the FTC Act.[0] Outside the US, Amazon still requires you to disclose that they're sponsoring your reviews. [1]

[0] https://www.ftc.gov/business-guidance/resources/ftcs-endorse...

[1] https://affiliate-program.amazon.com/help/node/topic/GHQNZAU...

Also, amazon sells lots of counterfeit books now, so the author of the site makes money off these books but the people that actually write the books probably don't:

- https://news.ycombinator.com/item?id=32210256

- https://news.ycombinator.com/item?id=32287936

- and just reading the reviews on the books of everyone saying they are getting counterfeit books.

The author could link to a book seller that actually sells the real book, but then I guess they wouldn't get their kickback.

(updated post to appease people that would rather get next day shipping than support the authors of the books.)

> amazon only sells counterfeit books anymore

This statement is (obviously) false as 99.9+% of all books sold on Amazon are authentic. Yes, Amazon should do even more to combat counterfeit everything but inflammatory, false comments are not productive.

Every Tech book I've looked at in the past few month has reviews of people showing their counterfeit books they have received. I'm not sure why you are defending Amazon's practice of letting this go on.

The first book on that list has comments showing off the counterfeit book that the people have gotten!

Reviews on Clean code: This books is a fake. Don't buy it. Look at the images I posted.

Reviews On Mythical Man: ordered new book, got something that was used and marked up and Great book, terrible terrible print and binding quality (which I assume is just a counterfeit)

Reviews On Algorithms: Beware of counterfeits; do not buy from Amazon!

I'm not going through the entire list, but most of the tech books are all fakes.

I've bought several tech books in the past month such as Purely Functional Data Structures by Chris Okasak, none were fake. I think you'd get less push back if your rephrased the original post as more of a warning that books ordered may be fake.

Amazon has a serious counterfeiting problem. They need to clean house.

i agree with disclosure on a moral/ethical basis, but cynically, how exactly is the FTC Act meant to be enforced? what is the point of making laws that cannot be enforced?

As someone who has read perhaps 75% of the books listed there, the outcome I got is: you need to learn the rules only to be able to discard them. Plenty of the "principles", "patterns", "laws", "good practices" that abound in these books are not only irrelevant but dangerous in plenty of real-world scenarios. From introducing an hierarchy of abstractions soon in the project, to apply blindly Brook's law, to using Scrum all the time... The real deal is to be able to say: "I know that most of you guys will say 'Let's apply Pattern X to this problem!', and while M. Fowler would also agree, based on similar projects we have done in the past, we definitely should not use Pattern X".

There is nothing more dangerous than an engineer that after having read all these books, is incapable of accept that sometimes following M. Fowler is the wrong path to solve that little problem we have at hand.

Absolutely. No book should be taken as word of law for software development. I like to think of books as a collection of ideas to expand my mind and then I can use judgement to choose to apply them as appropriate.

The danger is all the cargo-culting that is rampant among software “engineers”. They know all the patterns and repeat all the acronyms and phrases, while they have very little idea about the whys.

> There is nothing more dangerous than an engineer that after having read all these books

I disagree to some extend. We learn the rules, so we know when to break them. This is called improvisation. I think its worse to break the rules without even knowing why they are there in the first place.

I have read many of these books, and don't think its much of a concern because they often don't even agree with each other, and anyone paying the slightest attention to what they are reading will wrestle with the tension.

Sometimes they don't strictly disagree, but are different enough you must synthesize an even better idea!

For example, in "Philosophy of Software Design", Ousterhout recommends X, and then says Uncle Bob's advice is to do Y instead. When the experts don't agree, that should make you think "hmm, maybe this isn't settled."

In "Clean Architecture", Uncle Bob had a separate chapter (34 The Missing Chapter) written by Simon Brown which somewhat conflicts with the rest of the book.

> I have read many of these books, and don't think its much of a concern because they often don't even agree with each other, and anyone paying the slightest attention to what they are reading will wrestle with the tension.

I'm not sure you're the norm, at the very least a large number of engineers I've interacted with or mentored have come away from these books with either an explicit belief in these hard rules or an implicit one.

I've found Uncle Bob's work tends to be particularly bad in getting engineers into this mind set (though maybe I over-indexed because I think so much of his advice is bad).

In my experience, Uncle Bob's followers tend to be very dogmatic and somehow they think that only Uncle Bob's books are worth reading, so when you point out that maybe there is another valid perspective on the issue and not only Uncle Bob's, they look at you like you are crazy.

If you admit that you think that some of his books are pretty dated, or if you point out the examples he used to justify certain patterns are so contrived to make the other alternative look ridiculously stupid, or if you say that maybe our CRUD mobile app that only fetches data from the backend and displays it 1-1 doesn't need the 20 layers of clean architecture cargo culting, then they get angry and will label you as someone who "doesn't care and know about software architecture".

I'm not even sure why Uncle Bob is special in this regard, I have never met a Sandi Metz/Martin Fowler/John Ousterhout fan who could not comprehend that there are other valid points of view on a situation.

Shame these books didn't make the list:

Structure and Interpretation of Computer Programs: https://mitpress.mit.edu/sites/default/files/sicp/index.html

Concepts, Techniques and Models of Computer Programming https://www.info.ucl.ac.be/~pvr/book.html

The former is probably mentioned and well known enough, but it's surprising to me how few people know about the latter, or at least I rarely see it mentioned in "best computer books"

Thank you for introducing me to something new.

I would skip Uncle Bob and Marting Fowler's books and just read Code Complete. It has everything you might want to know about coding and then some.

Almost everything. I was scouring it a few weeks ago for some ideas on naming things according to analogies, for examples of analogies to draw from. Sadly it lacks this, and I still haven't found a good source for inspiration in that department. But yes, it's definitely like an encyclopedia of software construction.

It doesn't really cover enterprise patterns or refactoring in any depth, so I'm not sure why you'd replace Fowler. I agree skipping uncle bob is probably healthy for everyone though.

It has one chapter that sumarizes refactorings. Enterprise patterns or design patterns in general are about software design. IMHO design patters are the worst way to learn about design in software.

The fowler book on design patterns isn't really like gang of four or whatever - it's more descriptive of the different approaches you will really find in enterprise software vs. a bunch of fancy OO madness that turns junior engineers into architecture astronauts.

In terms of a dry 960 page reference book, with references to studies, Code Complete is good and I refer to it and tell others to refer to it. Uncle Bob's Clean Code covers the same ground, but the book has a narrative drive, gives examples, and is stylistically well written (although people may or may not agree with certain ideas).

I think both books are good but I usually recommend people read Clean Code first. It is an easier read, and it is also half the size so they're more likely to finish it.

Lots of stuff on here that I've been meaning to read. A few more I'd recommend are A Philosophy of Software Design, SQL Performance Explained, Mastering Regular Expressions, and Design Patterns (GOF). All for different reasons, but I feel like they're all great books to help explore various ideas, from more implementation level to high level overviews of software design.

Clean Code is solid. A bit radical in my opinion, but there's some good stuff in there.

Pragmatic Programmer was surprisingly good. I came into it thinking it would be very shallow since it tried to be wide reaching, but it was actually a lot of good general ideas to be refreshed every now and then. Works well as an audio book.

Designing Data-Intensive Applications was very good. Some stuff is hard to apply when you work on smaller scale software, but there's a lot of great content in there. The visualizations are huge for helping understand a lot of this

I also recommend A Philosophy of Software Design, the book taught me a lot about how to manage complexity in programming.

Do we need yet another site that recommends the same 10 books? I think practically every search for the best dev books will list Code Complete and The Mythical Man Month at this point

There are a lot more than 10 books on that list.

Because contrary to the site's name, a bunch of those books aren't even about software engineering.

Solid recommendations.

Mythical Man Month and Peopleware have been the best books I've ever purchased from a financial return on investment perspective. Required reading for any technology professionals.

What did you get out of these books?

mythical man month : “adding resources to a late software project only makes it later”, and gives you an authoritative reference to throw at everyone who hasn’t read it and thinks that “hey if I give you double the headcount can you finish the project in half the time?” It happens a lot in real life :/

I apply the concepts from MMM in professional contexts probably more than all other books combined. So many absolute timeless gems.

* No silver bullet

* 2nd system effect

* Mythical man month (adding people to a late project makes it later)

* "Question: How does a large software project get to be one year late? Answer: One day at a time!"

* Separate architecture and implementation

* "The Surgical Team" about technical team structure

Also an important takeaway from TMMM: people were having the same problems and trying the same approaches to solve them over 50 years ago.

A much better understanding of what it means to manage software engineering projects and work within a software engineering organization.

These understandings are valuable as an individual contributor: you are more self managing, which increases your perceived value (in healthy orgs), and are able to understand the machinations of a software org, which is good for your sanity and effectiveness.

Tom DeMarco is a fantastic author. His book "Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency" is incredibly helpful if you're on a team that faces anything listed in that subtitle

You're better off skipping Clean Code, for reasons detailed here[0].

[0]: https://qntm.org/clean

I disagree. It has plenty of useful information, but you have to take it all with a grain of salt. I'd much rather work with someone who has read and tries to apply Clean Code than someone who writes a 1000 line function.

> I'd much rather work with someone who has read and tries to apply Clean Code than someone who writes a 1000 line function.

Surely you recognise this is totally a false dichotomy?

I’d rather work with well structured 1000 line function than dozen useless functions from Clean Code.

I know exactly what you mean. I'm so happy that he only wrote about Java. Hardly imaginable how many damage this book would cause if it's written about C++.

Some of his points are good, some are bad. I think Clean Code should be read, but not considered the Bible. It's a good work with some flaws.

Thank you very much! Really! Since some years I puzzle to find out why the most Java programmers write code that is as shitty as it is. With tons of methods that are just doing more ore less nothing and you need to jump through 42 classes to find out what the code is really doing. It's a mess of code overhead that leads to nothing than more code overhead. Now I know, it's because the existance of this book and most Java programmers think thats the clean way to code. Unbelievebal.

I sincerely doubt most Java programmers have even read the book

Clean Code has 4 great chapters, quite a lot of outdated Java-ese, and some in between.

Sorry, but I can't take seriously any list that starts off with Clean Code.

Why? I have heard it recommended but I haven't read much of it.

A lot of people just don't like the author, so viscerally react negatively to the book itself. As a book in and of itself, it's a bit opinionated and maybe a little outdated, but no more so than The Pragmatic Programmer, The Mythical Man-Month, Code Complete, Patterns of Enterprise Architecture, Refactoring and Code (I haven't read the other two books in OP's Software Engineering section, so can't speak to them). It's entertaining to read and something you could finish on a long plane ride - there's good advice in there, but you won't really learn anything like you would if you read, say, Knuth.

I think what people dislike about Code Complete and Uncle Bob is all the dogma. I.e. You _MUST_ do this or you're not a professional and should feel bad.

The book contains some really bad advice (like using instance variables for temporary state instead of passing values via method parameters, with the rationale that parameter-less method calls are easier to read), and you need to already be quite experienced to tell the good from the bad.

Eeew yeah, that is REALLY bad.

Clean Code is one of the best books I've ever read. I don't even code in Java.

Maybee thats the reason ;P

Clean Code is not bad in itself. The problem is that some people made it a bible, like the absolute truth (I guess it is written in that way), and that's where it fails.

During my undergrad I semi-randomly picked out "Beautiful Code" [0] from our university library. Not sure why it never features in such lists but I thoroughly enjoyed it. :)

[0]: https://www.amazon.com/Beautiful-Code-Leading-Programmers-Pr...

I really love this book. Beautiful data and beautiful visualizations are also nice reads, but beautiful code has a special place in my heart.

+1 I really enjoyed these books. I wish there were more books in this series

SICP, K&R C, and TAOCP are the holy trinity.

* https://mitpress.mit.edu/sites/default/files/sicp/index.html

* https://kremlin.cc/k&r.pdf

* https://www-cs-faculty.stanford.edu/~knuth/taocp.html

Thank you for sharing this.

I would also to recommend these books [0]. They are books that may help you on programming journey. The site owner listed books in order from beginner to master.

[0]: https://www.programmingbooks.dev

A lot of tech books focus on a steady state. Use this for that job, have 8 engineers per team and put two on calls every week, micro service and kubernetes everything, do DevOps, automate every bit of CI/CD etc. The thing is, it really depends on what stage you are in. Evolve your organisation accordingly, there is no one size fit all solutions. How did a river form? Don't blindly build a river. Otherwise you become the fish that swims within never realising how you come there in the first place.

Notable exception is mythical man month. It describes transitions rather than steady states which put a lot of things into perspective imo.

Having said that, engineering books do provide a map of reality. A map is a map. That goes a long way

I made a list a few years ago, "Books I recommend to my software engineering students".

https://austinhenley.com/blog/booksformystudents.html

A personal favorite that I have read recently is Web Scalability for Startup Engineers: https://tinyurl.com/5x82psn8. Such a gem of a book for anyone who wants to get into the design of scalable systems. It is easy to follow by my less technical brain and very well structured.

Kent Beck's Test Driven Development by Example and Xtreme Programming Explained are delightful books that deserve a place on this list.

Nice list! I love that the Code by Charles Petzold is on it!

I created something similar out of my list of books which I used to navigate the transition to a Tech Lead role: https://techleadcompass.com/. I see that some of the books presented on the OP's list overlap with my list.

These are helpful. Thanks for sharing them!

Hasn't been mentioned in the thread yet, but the Phoenix Project is also excellent for senior engineers/managers.

I read it once when I was a junior engineer and didn't get much out of it, then again 6 years later and it was _excellent_.

I recommend The Goal as another reading, I think it does a better job on covering the Theory of Constraints aspects compared to TPP, but TPP does a good job of connecting that idea to IT work and software development.

Goldratt's sequels to The Goal are worth a read, too, but The Goal covers the more critical parts (IMO).

This is perhaps off-topic. I once found the table of contents of what seemed to be a very good and thorough book on operating systems, maybe associated with MIT. Unfortunately I lost the link. I know this isn't much to go off, but is anyone here aware of something like this, or does anyone have recommendations for a good textbook?

Thanks.

https://pdos.csail.mit.edu/6.828/2018/xv6/book-rev11.pdf, possibly?

Instead of (or possibly in addition to) "The Toyota Way", which seems to be listicle-fied, read "The Machine that Changed the World" by James Womack, Daniel Jones and Daniel Roos. It goes into deep detail and analysis of the way that the Toyota management principles infuse across the entire business.

It’s time we fork a « software design » category from the software engineering catchall.

Yet many great suggestions on this topic but one is missing, which in my opinion sums up a lot of the software design classics : « The Design of Everyday Things » by Don Norman.

Great list but missing dave farley's books on continuous delivery and modern software development.

Is see clean code but references about hexagonal architecture could be way more impactful, IMHO

Cormen et.al. is a great algorithms textbook, but I'm wondering in what world does it pass as a quick reference?

What I hated about that book is that it's full of exercises (good!) but no answers are provided (bad!). I really don't understand the mentality behind providing such good exercises with no way to check your answers - and they're not the kind of problems that you can verify your answer to, either.

They have started providing some answers: https://mitp-content-server.mit.edu/books/content/sectbyfn/b...

There are other sources on the web with answers. For example, https://sites.math.rutgers.edu/~ajl213/CLRS/CLRS.html

Often you can find some solutions to problem sets on course pages that use the book.

I agree that it would be better to provide solutions, but not all textbooks are written to be used in self-study. I don't know enough about CS to offer up any concrete recommendations, but there are math books that come with worked problems (e.g., https://www.springer.com/series/3423) and other math books that don't have worked problems (https://www.springer.com/series/666).

I have always thought that Robert Sedgewick's books are better in this respect (https://sedgewick.io/books/algorithms/). And for interview preparation too.

any recommendation for data structure / algoritms?

I really enjoyed Common-Sense-Guide-Structures-Algorithms https://www.amazon.com/Common-Sense-Guide-Structures-Algorit...

Since it was more pragmatic and less math driven.

Cormen et al (Introduction to Algorithms, first in OP's quick reference books) is a decent book on data structures and algorithms, although I'm always irritated that it doesn't include answers to the exercises. I read Sedgewick's "Algorithms" in college and I remember it being pretty good. Knuth (The Art of Computer Programming) is amazing, but be prepared to invest a lot of time into it (them).

Algorithm Design Manual

A crap list. Why is there "Essential Scrum"?

That site is throwing off strong "affiliate link niche site" vibes.

Not only why is there a garbage book like "Essential Scrum", why is there no mention of any unit testing or TDD books? If the author is seriously going to plug Martin Fowler's Refactoring book but make no effort to call out any books to help guide in writing good quality tests, I'm starting to have serious doubts about the nature of those "10 years of experience". I don't care if you "buy into" TDD or not - refactoring without test coverage is flat-out "Cowboy coding": reckless & irresponsible.

> refactoring without test coverage is flat-out "Cowboy coding": reckless & irresponsible.

This is basically what Fowler says in his refactoring book. Actually, he says it's by definition not refactoring. I'm curious why you don't think it's worth reading.

I suspect GP's complaint is not with Fowler, but with the list not including books that complement it. Like Beck's Test-Driven Development or Feathers' Working Effectively with Legacy Code or some others.

Yes! This is exactly my point. Having included something as fluff as "Essential Scrum" on TOP of skipping Beck's "TDD by Example" or Feathers' "Working Effectively with Legacy Code" is very regrettable.

Honest question: what is wrong with Essential Scrum?

You can skip the tar pit of the Scrum Industrial complex (e.g. "here! you MUST take our certificate program!") and the drag setting pointless sprint boundaries and focus on just repeatedly, successfully, ship high quality software. The Accelerate book is a very good starting point - https://www.amazon.com/Accelerate-Software-Performing-Techno...

https://qntm.org/clean

Read Code Complete first then read Clean Code with a healthy dash of skepticism and do not follow it blindly. I still think Clean Code is a great book but does fall into "the one true way" and dogmatism.

This is the advice I give junior developers. I explain that Clean Code turns everything up to 11 and can make the code less readable then more if followed without thought.

Clean Code includes this near the start:

> Consider this book a description of the Object Mentor School of Clean Code. The techniques and teachings within are the way that we practice our art. We are willing to claim that if you follow these teachings, you will enjoy the benefits that we have enjoyed, and you will learn to write code that is clean and professional. But don’t make the mistake of thinking that we are somehow “right” in any absolute sense. There are other schools and other masters that have just as much claim to professionalism as we. It would behoove you to learn from them as well.

> Indeed, many of the recommendations in this book are controversial. You will probably not agree with all of them. You might violently disagree with some of them. That’s fine. We can’t claim final authority. On the other hand, the recommendations in this book are things that we have thought long and hard about. We have learned them through decades of experience and repeated trial and error. So whether you agree or disagree, it would be a shame if you did not see, and respect, our point of view.

Dogmatic texts generally don't tell you to go find other places to learn from.

But Clean Code BAD. Don't you know?

Chances are these commenters haven't even opened the book.

Perhaps, but this is far from the only time that book has been criticized on these forums. Here's a comment from the past month alone that goes into why Clean Code has not aged well.

https://news.ycombinator.com/item?id=31978877

It's from a thread discussing a 2017 article critiquing the book. https://news.ycombinator.com/item?id=31978465

Reply on news.ycombinator.com