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.”
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.
> “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.”
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]
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:
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.
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.
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.
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 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"
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.
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.
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.
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
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
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.
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
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.
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 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 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++.
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.
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.
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.
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.
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. :)
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.
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
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.
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.
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?
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.
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.
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.
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).
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.
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...
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.
> 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.
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.
