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.”
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.
> “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:
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.
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.
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.
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.
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.
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.
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?
[+] [-] CharlieDigital|3 years ago|reply
[+] [-] digdugdirk|3 years ago|reply
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?
[+] [-] j1elo|3 years ago|reply
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.
[+] [-] amelius|3 years ago|reply
Except those who code in Whitespace.
https://en.wikipedia.org/wiki/Whitespace_(programming_langua...
[+] [-] renox|3 years ago|reply
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..
[+] [-] mtlynch|3 years ago|reply
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...
[+] [-] user00012-ab|3 years ago|reply
- 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.)
[+] [-] swyx|3 years ago|reply
[+] [-] sdevonoes|3 years ago|reply
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.
[+] [-] Ma8ee|3 years ago|reply
[+] [-] clumsysmurf|3 years ago|reply
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.
[+] [-] jjice|3 years ago|reply
[+] [-] craigching|3 years ago|reply
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"
[+] [-] unknown|3 years ago|reply
[deleted]
[+] [-] PTOB|3 years ago|reply
[+] [-] gashmol|3 years ago|reply
[+] [-] Ologn|3 years ago|reply
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.
[+] [-] itsdrewmiller|3 years ago|reply
[+] [-] ironmagma|3 years ago|reply
[+] [-] jjice|3 years ago|reply
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
[+] [-] ChrisRR|3 years ago|reply
[+] [-] xiande04|3 years ago|reply
[+] [-] beckingz|3 years ago|reply
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.
[+] [-] yakshaving_jgt|3 years ago|reply
[0]: https://qntm.org/clean
[+] [-] shepherdjerred|3 years ago|reply
[+] [-] yCombLinks|3 years ago|reply
[+] [-] krater23|3 years ago|reply
[+] [-] urthor|3 years ago|reply
[+] [-] graynk|3 years ago|reply
[+] [-] dimgl|3 years ago|reply
[+] [-] dcu|3 years ago|reply
[+] [-] kube-system|3 years ago|reply
[+] [-] black_puppydog|3 years ago|reply
[0]: https://www.amazon.com/Beautiful-Code-Leading-Programmers-Pr...
[+] [-] dongecko|3 years ago|reply
[+] [-] throwaway093433|3 years ago|reply
* 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
[+] [-] 0x54MUR41|3 years ago|reply
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_c|3 years ago|reply
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
[+] [-] azhenley|3 years ago|reply
https://austinhenley.com/blog/booksformystudents.html
[+] [-] rochak|3 years ago|reply
[+] [-] mindless_solips|3 years ago|reply
[+] [-] poushkar|3 years ago|reply
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.
[+] [-] bsamuels|3 years ago|reply
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_.
[+] [-] acutis_fan|3 years ago|reply
Thanks.
[+] [-] Jtsummers|3 years ago|reply