Programmers Don't Read Books – But You Should (2008)(blog.codinghorror.com)
blog.codinghorror.com
Programmers Don't Read Books – But You Should (2008)
https://blog.codinghorror.com/programmers-dont-read-books-but-you-should/
47 comments
Many are outdated by the time they hit the press.
I recall a few years back, Packt et al would publish like "Modern React" or something, with examples that wouldn't build by the time the book was out.
Typesetting is awful too, as you mentioned. A single paragraph for something dead simple is spread over multiple pages.
Nothing against such authors; its fruitless to hit a moving target.
Books on programming languages are the only ones I purchase these days, for those reasons.
The Go book, Rust Programming language, Stroustrup's books on C++ etc are quite good and worth owning, but those are exceptions rather than the rule.
I recall a few years back, Packt et al would publish like "Modern React" or something, with examples that wouldn't build by the time the book was out.
Typesetting is awful too, as you mentioned. A single paragraph for something dead simple is spread over multiple pages.
Nothing against such authors; its fruitless to hit a moving target.
Books on programming languages are the only ones I purchase these days, for those reasons.
The Go book, Rust Programming language, Stroustrup's books on C++ etc are quite good and worth owning, but those are exceptions rather than the rule.
>Nothing against such authors;
I have something against them. It's often apparent that many of them are professional programming book authors that are learning the language as they are writing the book instead of being professional programmers with some skills in the language that are writing a book. I don't want to learn along with another unskilled person, I want to learn from someone that has enough familiarity to not use features incorrectly and to mention potential hangups. Hell a lot of these books read like they are written by someone that is new to programming altogether, not just someone that is relatively new to the language.
I have something against them. It's often apparent that many of them are professional programming book authors that are learning the language as they are writing the book instead of being professional programmers with some skills in the language that are writing a book. I don't want to learn along with another unskilled person, I want to learn from someone that has enough familiarity to not use features incorrectly and to mention potential hangups. Hell a lot of these books read like they are written by someone that is new to programming altogether, not just someone that is relatively new to the language.
Programming books are definitely becoming more hit or miss, as the volume of books has increased dramatically in the last 10-15 years. There are still great books, but there are a lot more bad ones out there. There's a lot more software out there, and a lot more people learning about it.
I had a horrible experience with Packt. I had subscribed andwas in the middle of reading a book. The book suddenly became unavailable, so I created a ticket. They threw a few tokens at me, and asked if they could just close the ticket, even though there was no mention of whether the book was going to be available again.
Then weeks later they signed me up for six(!) separate mailing lists without asking me, one for each tag I had flagged as interested.
I had a horrible experience with Packt. I had subscribed andwas in the middle of reading a book. The book suddenly became unavailable, so I created a ticket. They threw a few tokens at me, and asked if they could just close the ticket, even though there was no mention of whether the book was going to be available again.
Then weeks later they signed me up for six(!) separate mailing lists without asking me, one for each tag I had flagged as interested.
> I recall a few years back, Packt et al would publish like "Modern React" or something, with examples that wouldn't build by the time the book was out.
This says more about React than it does about the publisher.
This says more about React than it does about the publisher.
Churn in the software world is out of control, and I have no idea why we accept it.
It's funny because at the end of the day it's still all just instructions on a CPU. Computers essentially haven't changed in half a century. What the biggest change between then and now? Multi-core processors?
I'd say the computer architecture can vary _greatly_ and there are a bunch of cores in modern SOC's that kind of break the assumption of how a computer works. I recently listened to this:
https://youtu.be/36myc8wQhLo?si=sWdKyW3w2vln93SP
Cache coherence, accelerators, various takes on pipelining, ISA extensions. There are many many things that change all the time.
Not even touching the SW glue stuff that changes. I don't know the history of react and what is going on in modern browsers, but I suspect there are OS constraints, evolving web standards, extra capabilities, evolving browsers that shape and force the framework to adapt. I am doubtful people change it just for the sake of it.
https://youtu.be/36myc8wQhLo?si=sWdKyW3w2vln93SP
Cache coherence, accelerators, various takes on pipelining, ISA extensions. There are many many things that change all the time.
Not even touching the SW glue stuff that changes. I don't know the history of react and what is going on in modern browsers, but I suspect there are OS constraints, evolving web standards, extra capabilities, evolving browsers that shape and force the framework to adapt. I am doubtful people change it just for the sake of it.
We are talking about programming computers. What the CPU does once it gets instructions is mostly irrelevant to the programmer. The act of programming is still just building big lists of instructions to feed to a CPU so why has the programming stack grown to such a massive precarious bloated pile of abstraction that gets in my way? Every fancy schmancy language you can think of still just comes down to feeding the same instructions to a hungry CPU.
That's the thing, you have layers upon layers of stuff that run on the computer. You have a runtime of the language, many many abstractions of interacting with the various capability of the system, a ABI to the OS, an ISA. These things vary and you need to account somehow for these variation. And the changes in the lowest layers percolate through.
Not to mention that the computer is actually very very different than what you imagine.
I say this not to make excuses for react, again I don't know that ecosystem. I spend most of my time writing firmware and low level drivers. And I see during my work the wide array of capabilities and approaches these systems have. They are not an homogeneous bunch.
Not to mention that the computer is actually very very different than what you imagine.
I say this not to make excuses for react, again I don't know that ecosystem. I spend most of my time writing firmware and low level drivers. And I see during my work the wide array of capabilities and approaches these systems have. They are not an homogeneous bunch.
I'd say GPUs and the things descended from them and how they're being used now is a pretty big development.
You can still be reductionist about it, but it feels materially different from the mundane calculations and algorithms that sprung to mind when I read your post.
You can still be reductionist about it, but it feels materially different from the mundane calculations and algorithms that sprung to mind when I read your post.
Agreed. GPUs are a somewhat different paradigm.
O'Reilly, Manning, Pragmatic, No Starch, and Addison-Wesley are generally high quality publishers.
Packt appears to be a vanity press.
React is a difficult moving target, and Packt is a six year old with a homemade slingshot.
Packt appears to be a vanity press.
React is a difficult moving target, and Packt is a six year old with a homemade slingshot.
The most useful books to read are about topics that don’t get easily outdated.
>Many are outdated by the time they hit the press.
Quite a while back, I was contacted by Wiley about writing an OpenStack book. I wasn't the right person to write it anyway. But even if I were, by the time the book hit the shelves, OpenStack would almost certainly have moved on a good two versions.
Quite a while back, I was contacted by Wiley about writing an OpenStack book. I wasn't the right person to write it anyway. But even if I were, by the time the book hit the shelves, OpenStack would almost certainly have moved on a good two versions.
That's exactly the author's point:
2 - http://www.amazon.com/exec/obidos/ASIN/0321965515/codihorr-2...
3 - http://www.amazon.com/exec/obidos/ASIN/0932633439/codihorr-2...
4 - http://www.amazon.com/exec/obidos/ASIN/020161622X/codihorr-2...
5 - http://www.amazon.com/exec/obidos/ASIN/0321117425/codihorr-2...
Most programming books suck.
But I do have this call to arms: my top five programming books every working programmer should own – and read.
Code Complete 2 [1]
Don't Make Me Think [2]
Peopleware [3]
Pragmatic Programmer [4]
Facts and Fallacies [5]
2 - http://www.amazon.com/exec/obidos/ASIN/0321965515/codihorr-2...
3 - http://www.amazon.com/exec/obidos/ASIN/0932633439/codihorr-2...
4 - http://www.amazon.com/exec/obidos/ASIN/020161622X/codihorr-2...
5 - http://www.amazon.com/exec/obidos/ASIN/0321117425/codihorr-2...
> I don't read programming books any more because they are mostly shit or expensive or expensive and shit.
That’s consistent with the first reason given in the article:
> I lay part of the blame squarely at the feet of the technical book publishing industry:
> Most programming books suck. The barrier to being a book author, as near as I can tell, is virtually nonexistent. The signal to noise of book publishing is arguably not a heck of a lot better than what you'll find on the wilds of the internet. Of the hundreds of programming books released every year, perhaps two are three are truly worth the time investment.
That’s consistent with the first reason given in the article:
> I lay part of the blame squarely at the feet of the technical book publishing industry:
> Most programming books suck. The barrier to being a book author, as near as I can tell, is virtually nonexistent. The signal to noise of book publishing is arguably not a heck of a lot better than what you'll find on the wilds of the internet. Of the hundreds of programming books released every year, perhaps two are three are truly worth the time investment.
I’m the author of Learning Go from O’Reilly, so I might be a bit biased.
What I’ve found is that different publishers put different amount of effort into producing good content. O’Reilly is almost always excellent. Others are less so.
It’s hard to find a dev who is willing to invest a year of their life to write a book that is likely to make almost no money. It’s doubly hard to find devs who write well.
Given these filters, two or three good programming books a year sounds pretty great.
What I’ve found is that different publishers put different amount of effort into producing good content. O’Reilly is almost always excellent. Others are less so.
It’s hard to find a dev who is willing to invest a year of their life to write a book that is likely to make almost no money. It’s doubly hard to find devs who write well.
Given these filters, two or three good programming books a year sounds pretty great.
what a coincidence!
i am reading your book now and thoroughly enjoying it!
Learning Go's quite good to get dangerous with Go quickly, so good job!
i am reading your book now and thoroughly enjoying it!
Learning Go's quite good to get dangerous with Go quickly, so good job!
The problem is that they're written by developers. And when I say developers I mean developers, not engineers or authors. Everything is about a sausage factory, nothing more. You don't learn stuff other than copying and mimicry. And some of it is absolute monkey excrement. But when you don't know better it feels like you are learning something good.
I am considering writing a bad programming book on purpose. I will call it "how to sling together a badly written Go 'enterprise' app and smear AngularJS over the top"
I am considering writing a bad programming book on purpose. I will call it "how to sling together a badly written Go 'enterprise' app and smear AngularJS over the top"
Nah, the worst ones are the ones written by authors, but who aren't developers. Especially the ones that are authors that just write a book for every new trendy language but never get to the point of actually using those languages themselves.
The really good books are REALLY good, though. But the only places I've seen them were at university bookstores (and even then mainly MIT/Stanford) or Amazon when they had physical stores. Otherwise you have to get them online
From Mark Burguess I'm reading:
- The Unix Programming Environment (not that one; this one it's a bit more modern). You'll get a bit of Perl instead of AWK, but it's fine.
- The GNU C Tutorial. Not as good as 'The C programming language'; but still useful.
- A shot Introduction To Operating Systems. Slightly outdated C++, because most of the time the issue it's just about fixing the include headers.
Most of the things learned there will work as is as Perl5, ANSI C/GNU C and so don't change a lot over time, if any.
- The Unix Programming Environment (not that one; this one it's a bit more modern). You'll get a bit of Perl instead of AWK, but it's fine.
- The GNU C Tutorial. Not as good as 'The C programming language'; but still useful.
- A shot Introduction To Operating Systems. Slightly outdated C++, because most of the time the issue it's just about fixing the include headers.
Most of the things learned there will work as is as Perl5, ANSI C/GNU C and so don't change a lot over time, if any.
And then you also have the books which cost 60€ and aren't even printed in color. I mean it makes sense for ecological reasons, but I can get books for 19€ that are colorized.
It would be a much better reading experience if some boxes would actually show colorized instead of different shades of grey.
There’s always LibGen and friends if you really can’t afford much, or to sample before buying. You can also get used copies cheaper. The pricing shouldn’t keep you from reading.
I saw an HN thread a while back where someone recommended a comprehensive book on some networking subject. I'm sure it was a good book, I was floored when I saw physical copies being sold fucking $700.
Unfortunately, a lot of the technical books I wish to read fall into this grift of academic texts.
Unfortunately, a lot of the technical books I wish to read fall into this grift of academic texts.
I try and re-read Fred Brooks' _Mythical Man Month_ every year or two. That is a short series of essays that I seem to always find a "new" idea from. My most recent re-read the line that stuck with me was "plan to throw one away. You will anyhow."
What I took from that given the situation I was in at time was that the best way to build an abstraction is to build the first one without any abstraction, and only then, when you understand how whatever is being abstracted will be used, try and build the abstraction layer, rather than starting with the attempt at abstraction. There are other ways to interpret it- it can point you to a more Agile design philosophy even though he was writing decades before the Agile Manifesto.
What I took from that given the situation I was in at time was that the best way to build an abstraction is to build the first one without any abstraction, and only then, when you understand how whatever is being abstracted will be used, try and build the abstraction layer, rather than starting with the attempt at abstraction. There are other ways to interpret it- it can point you to a more Agile design philosophy even though he was writing decades before the Agile Manifesto.
" The Design of Everyday Things" is a great non-programming book that programmers should read. It tells you why/how you should make things more usable for your users. If you find yourself failing to use something properly, it's not you being stupid, it's the design.
Design of doors is famously known example from this book.
Design of doors is famously known example from this book.
I often think about the idea that a good design takes information from the world (or the users head) and puts it into the system, reducing cognitive load. So if a door needs to be pushed, put a push plate on it, rather than requiring the user to remember to push the handle. Think about it when labelling buttons quite a bit, for example. Or workflows.
Or even when writing code, think about whoever is going to read or use your code.
Another idea was about suggestive nature of design. If top of a small wall is flat, practically it's asking you to put your empty can on it.
Another idea was about suggestive nature of design. If top of a small wall is flat, practically it's asking you to put your empty can on it.
Some counter-examples:
- Structure and Interpretation of Computer Programs
- C Interfaces and Implementations
- Design Patterns
- Compilers: Principles, Practice and Tools
Each of these should make you go "a-ha!", in its own way.
- Structure and Interpretation of Computer Programs
- C Interfaces and Implementations
- Design Patterns
- Compilers: Principles, Practice and Tools
Each of these should make you go "a-ha!", in its own way.
Design Patterns is your suggestion of a book that isn't shit? Even the list of "a-ha" books has random landmines tossed in.
The Gof book should be on the list, but I agree that it suffers from similar problems that a lot of first-of-their-kinds do. There are iterations on it that are a much better read.
This also isn't a programming book. It's a business methodology book that is probably more harmful than beneficial.
None of you I proposing better alternatives though nor what is wrong with it though.
Another good book (also quite timeless) is Osterhout's Philosophy of Software Design (though it's less philosophical than the title might suggest).
Amusingly, I thought Code Complete was disliked now? I thought it was fun, but definitely over sold on things.
I liked the other ones, even if I don't remember take aways from them at the moment.
I do reject the Knuth observation here. Annoyingly, most criticism you will ever see of a Knuth book are from people that never read them. Not that I don't get the point, as following closely behind that group are those that bought but never read them. Especially with the newer volumes, there are a lot of very fun topics covered.
And, sure, you are best not putting together many of the low level things that are covered in those books. But... you are also best not blindly following whatever is in the other books, too? Again, many folks dislike Code Complete for fairly solid reasons.
I liked the other ones, even if I don't remember take aways from them at the moment.
I do reject the Knuth observation here. Annoyingly, most criticism you will ever see of a Knuth book are from people that never read them. Not that I don't get the point, as following closely behind that group are those that bought but never read them. Especially with the newer volumes, there are a lot of very fun topics covered.
And, sure, you are best not putting together many of the low level things that are covered in those books. But... you are also best not blindly following whatever is in the other books, too? Again, many folks dislike Code Complete for fairly solid reasons.
Code Complete seems more forgotten than disliked these days (rarely mentioned, either for or against). Clean Code is the one that, when you mention it, brings out all the negative comments.
Ah, makes sense! I am pretty sure I've read them both. I'm not too surprised that I would mistake them for each other. Will have to look back at Code Complete. :D
Maybe consider a subscription to Safari Bookshelf instead. Everywhere I've ever worked, they've been happy to foot the bill for an annual subscription so I have a deep reference library.
A few years ago, O'Reilly had a 60% off sale for an annual subscription, which I promptly took advantage of. I've been paying only $200 per year ever since. Not sure if they still have that deal.
Yes, $200 per year is a great deal. For those who are ok with reading digital content, Safari is where it's at, in my opinion.
I actually find the quality of programming books to have starkly increased in the last decade. I find a lot of manning's and o'reilly's release to have a pretty long shelf-life.
For example, I really enjoyed and often go back to:
- https://www.oreilly.com/library/view/building-event-driven-m...
- https://www.oreilly.com/library/view/designing-data-intensiv...
- https://www.manning.com/books/100-go-mistakes-and-how-to-avo...
- https://www.amazon.com/Systems-Performance-Brendan-Gregg/dp/...
And more recently:
- https://www.manning.com/books/build-a-large-language-model-f...
- https://www.manning.com/books/the-creative-programmer
- https://www.manning.com/books/the-programmers-brain
- https://www.amazon.com/Understanding-Software-Addison-Wesley...
I also find books about specific technologies that indeed run the risk of being deprecated after a few years to be useful too
- https://www.oreilly.com/library/view/networking-and-kubernet...
- https://www.brendangregg.com/bpf-performance-tools-book.html
Furthermore, nothing keeps you from reading books about topics peripheral to computer science, say to keep up with the general vibes:
- https://www.amazon.com/Probabilistic-Machine-Learning-Introd...
- https://www.amazon.com/Deep-Learning-Foundations-Christopher...
- https://www.amazon.com/Joy-Abstraction-Exploration-Category-...
I find that all of these contribute significantly to my growth as an engineer.
For example, I really enjoyed and often go back to:
- https://www.oreilly.com/library/view/building-event-driven-m...
- https://www.oreilly.com/library/view/designing-data-intensiv...
- https://www.manning.com/books/100-go-mistakes-and-how-to-avo...
- https://www.amazon.com/Systems-Performance-Brendan-Gregg/dp/...
And more recently:
- https://www.manning.com/books/build-a-large-language-model-f...
- https://www.manning.com/books/the-creative-programmer
- https://www.manning.com/books/the-programmers-brain
- https://www.amazon.com/Understanding-Software-Addison-Wesley...
I also find books about specific technologies that indeed run the risk of being deprecated after a few years to be useful too
- https://www.oreilly.com/library/view/networking-and-kubernet...
- https://www.brendangregg.com/bpf-performance-tools-book.html
Furthermore, nothing keeps you from reading books about topics peripheral to computer science, say to keep up with the general vibes:
- https://www.amazon.com/Probabilistic-Machine-Learning-Introd...
- https://www.amazon.com/Deep-Learning-Foundations-Christopher...
- https://www.amazon.com/Joy-Abstraction-Exploration-Category-...
I find that all of these contribute significantly to my growth as an engineer.
> I actually find the quality of programming books to have starkly increased in the last decade.
I suspect this might be a side-effect of programmers buying less books. The ratio of authors who write them because they really care instead of because they hope to make some bucks would then increase.
I suspect this might be a side-effect of programmers buying less books. The ratio of authors who write them because they really care instead of because they hope to make some bucks would then increase.
Just picked up a few of these for my summer vacation. Appreciate the recommendations!
Computer programming books have a special place in my heart. I really like the idea of them. I think my brain is limited in how much it can retain from a book vs things I see and encounter daily though. My memory is optimized for urgent/important/daily use.
There’s a lot of non-programming books I really enjoy though as well.
There’s a lot of non-programming books I really enjoy though as well.
Just ambling around the book store earlier I saw a 3 inch think tome around Go programming called Pro Go or something. I opened it and it was a whole book of instructional copy and paste recipes that span 10 pages for a simple problem. Urgh. This is the status quo now and it has been for a long time. I walked out with a book on pure mathematics instead - probably more useful in the long run...