A Sense of Doubt blog post #1626 - Programmers don't read BOOKS and other BS

A Sense of Doubt blog post #1626 - Programmers don't read BOOKS and other BS
I like books.

Should that go without saying?

I don't think so. It needs to be said, written, repeated often.

As our world converts more and more to a digital experience, as the majority of reading that the majority of people do happens on a handheld device the size of a deck of playing cards (or a little bigger these days), as what started as an online bookstore and is now a store for everything eats the planet and heads to the stars, books need to keep their place in our hands, our hearts, and our minds.

I am not the only one who feels this way.

And, no, I am not old school or a dying breed.

Young people are still reading books. Often these are digital books or audio books. Heck, I indulge in both of those, but books are bought or borrowed, books are read or consumed, and we have stretched our definition of what it means to "read."

And so, it should surprise no one (it doesn't surprise me) that there's a movement away from books in programming circles. The Internet has become so robust and so useful -- especially with sites like STACK OVERFLOW, that provide many example cases and discussions for every conceivable programming design, issue, debug, construction, and style -- that the fact that many programmers claim not to read books and really criticize books as useless for learning programming should be so prevalent.

The main argument against programming books consists of a learn by doing approach. And, sure, programming cannot be learned without doing. One must code to learn to code, like with anything. No one learns to play the piano without playing the piano; no one learns to paint on canvas without painting on canvas. These analogies shine a light on the differences, though, too. Unlike music and the art of painting, programming depends on a vast base of knowledge that can be obtained through reading and be much more effective than learning to read music and play the music through reading a book about how it all works. At some point during the process, the coder will head to the computer and do the coding, but the doing of the thing does not devalue the reading about the thing.

There's a collection of links and text here shared from the links. The main content, copied in its entirety, comes from the famous CODING HORROR blog by Jeff Atwood, one of the founders STACK OVERFLOW, which is the main competitor in programming circles to reading books.

The consensus here is that many people still like to read books on programming and there are many good ones to read as well as ones that keep coming up again and again, such as CODE COMPLETE by Steve McConnell.




THE UPSHOT? Books on programming are important. But to learn to code, one must actually write code. But that's no reason not to read books.


If you like books, read books.


If you don't like to read books, then don't read them. Maybe you wont need them. Depends on what you are doing in the coding industry. But if need to consider abstraction, algorithm design, and other higher level ideas. then, maybe, reading books has great merit.


See what others have to say, especially from CODING HORROR.

THE CONTENTS OF THIS BLOG
Or not.... I am only copying the content from the first link, the rest will be annotated.Programmers Don't Read Books -- But You Should
https://blog.codinghorror.com/programmers-dont-read-books-but-you-should/




Why I don’t read books | Doug McCune
http://dougmccune.com/blog/2007/03/23/why-i-dont-read-books/

ANNOTATION: The copy/paste factor and learning by doing
Whenever I’m learning anything computer-related I’m doing it as I’m learning it. That’s the only way I can learn, and I’d be surprised if you find anyone who’s all that different (when it comes to computer programming).

ME: I agree. I like books, but when reading about doing things with computers, it's not as effective as reading and doing at the same time. That said, if I am reading in bed and trying to relax, I am not coding; however, I am familiarizing myself with the content.



What are the top five books every computer programmer should study at least once?- QUORA
https://www.quora.com/What-are-the-top-five-books-every-computer-programmer-should-study-at-least-once

Tikhon Jelvis, programming on my own and professionally for over a decade

Updated Oct 15, 2016 · Upvoted by Nupul Kukreja, Ph.D. Computer Science & Software Engineering, University of Southern California and Erika Olimpiew, Ph.D. Software Engineering & Information Technology, George Mason University (2008)

• The Structure and Interpretation of Computer Programs (SICP) is a wonderful introduction to programming, computer science and—most importantly—abstraction. It does an incredible job of quickly covering basic CS, including the major different programming paradigms. Most importantly, it helps impart a true CS mindset and shows the inherent beauty and elegance of the subject. You can read it for free online.

• Introduction to the Theory of Computation is one of the most readable texts I've come accross in any discipline. It gives a wonderful introduction to formal languages (not programming languages), computability and complexity. Apart from being a very accessible introduction to theoretical computer science, it also has an innovative structure for teaching proofs which I've found very valuable for learning to reason abstractly and formally without sacrificing clarity. It's well worth reading just for an example of how clear proofs can be.

• Artificial Intelligence: A Modern Approach (AIMA) is a strong introduction to AI. It covers the high level ideas necessary to approach the field as well as a nice covering set of basic AI algorithms. It's an incredibly popular text used in over 1200 universities.

• Types and Programming Languages (TAPL) is a good overview of modern programming language design and theory. It's a good place to get a handle on the field as well as catch up with the last few decades of programming language research, much of which is only entering the mainstream now if at all. It's good as both a starting point for learning more advanced languages (like Haskell) and for understanding the design and trade-offs in more popular languages like Java.

• Introduction to Algorithms is the standard reference on algorithms. It's good for both learning to design algorithms and just learning the standard set most programs rely on.

I actually learned algorithms with the prosaically named Algorithms by Dasgupta, Papadimitriou and Vazirani which was not too bad and is available free online.

Programmers don't read? Then why does this article recommend 40 books?
https://blog.soshace.com/en/2019/07/22/40-web-development-books/

Code: The Hidden Language of Computer Hardware and Software | Charles Petzold
Print Length: 400 pages
Publisher: Microsoft Press; 1 edition (October 11, 2000)
Publication Date: October 11, 2000

Code: The Hidden Language

No matter what your level of technical savvy, you’ll love this book: it’s more of non-fiction rather than a pure programming manual. It’s a fantastically well-written and researched gem that will appeal to both the general public and experienced engineers. And although it was published almost 20 years ago, it still continues to be relevant and praised by many. Using ordinary objects and language systems like Morse code and Braille, the author introduces the readers to the secret inner life of computers, digital media, and the Internet, meanwhile explaining technologies, number systems, logic gates, machine code, and programming languages in a down-to-earth and comprehensible fashion.

Code Complete 2 | Steve McConnell
Print Length: 960 pages
Publisher: Microsoft Press; 2 edition (June 9, 2004)
Publication Date: June 9, 2004

Code Complete

Code Complete is one of those programming bibles every engineer ought to have. And although it’s almost 1,000 pages long, it deserves to be read and re-read multiple times. To paraphrase one of the reviewers, Code Complete is perhaps the first and the most important monumental encyclopedia on the best practices in building quality software, covering subjects like building classes, using data and control structures, debugging, refactoring, and code-tuning. Albeit not updated, this book is still among the best practical guides on programming.

Keeping track of this author - publishing here - https://blog.soshace.com/en/

https://blog.soshace.com/en/author/vorontsova_mi/

Programmers Don't Read Books -- But You Should
https://blog.codinghorror.com/programmers-dont-read-books-but-you-should/

Programmers Don't Read Books -- But You Should

One of the central themes of stackoverflow.com is that software developers no longer learn programming from books, as Joel mentioned:

Programmers seem to have stopped reading books. The market for books on programming topics is miniscule compared to the number of working programmers.

Joel expressed similar sentiments in 2004's The Shlemiel Way of Software:

But the majority of people still don't read. Or write. The majority of developers don't read books about software development, they don't read Web sites about software development, they don't even read Slashdot.

If programmers don't learn from books today, how do they learn to program? They do it the old-fashioned way: by rolling up their sleeves and writing code – while harnessing the collective wisdom of the internet in a second window. The internet has rendered programming books obsolete. It's faster, more efficient, and just plain smarter to get your programming information online. I believe Doug McCune's experience, which he aptly describes as Why I Don't Read Books, is fairly typical.

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.
• Programming books sold by weight, not by volume. There seems to be an inverse relationship between the size of a programming book and its quality. The bigger the book, somehow, the less useful information it will contain. What is the point of these giant wanna-be reference tomes? How do you find anything in it, much less lift the damn things?
• Quick-fix programming books oriented towards novices. I have nothing against novices entering the programming field. But I continue to believe the "Learn [Insert Language Here] in 24 hours!" variety of books are doing our profession a disservice. The monomaniacal focus on right now and the fastest, easiest possible way to do things leads beginners down the wrong path – or as I like to call it, "PHP". I kid! I kid!
• Programming book pornography. The idea that having a pile of thick, important-looking programming books sitting on your shelf, largely unread, will somehow make you a better programmer. As David Poole once related to me in email, "I'd never get to do that in real life" seems to be the theme of the programming book porn pile. This is why I considered, and rejected, buying Knuth's Art of Computer Programming. Try to purchase practical books you'll actually read, and more importantly, put into action.

As an author, I'm guilty, too. I co-wrote a programming book, and I still don't think you should buy it. I don't mean that in an ironic-trucker-hat, reverse-psychology way. I mean it quite literally. It's not a bad book by any means. I have the utmost respect for my esteemed co-authors. But the same information would be far more accessible on the web. Trapping it inside a dead tree book is ultimately a waste of effort.

The internet has certainly accelerated the demise of programming books, but there is some evidence that, even pre-internet, programmers didn't read all that many programming books. I was quite surprised to encounter the following passage in Code Complete:

Pat yourself on the back for reading this book. You're already learning more than most people in the software industry because one book is more than most programmers read each year (DeMarco and Lister 1999). A little reading goes a long way toward professional advancement. If you read even one good programming book every two months, roughly 35 pages a week, you'll soon have a firm grasp on the industry and distinguish yourself from nearly everyone around you.

I believe the same text is present in the original 1993 edition of Code Complete, but I no longer have a copy to verify that. A little searching uncovered the passage Steve McConnell is referencing in DeMarco and Lister's Peopleware:

The statistics about reading are particularly discouraging: The average software developer, for example, doesn't own a single book on the subject of his or her work, and hasn't ever read one. That fact is horrifying for anyone concerned about the quality of work in the field; for folks like us who write books, it is positively tragic.

It pains me greatly to read the reddit comments and learn that people are interpreting the stackoverflow.com mission statement as a repudiation of programming books. As ambivalent as I am about the current programming book market, I love programming books! This very blog was founded on the concept of my recommended developer reading list. Many of my blog posts are my feeble attempts to explain key conceptsoutlined long ago in classic programming books.

How to reconcile this seemingly contradictory statement, the love and hate dynamic? You see, there are programming books, and there are programming books.
The best programming books are timeless. They transcend choice of language, IDE, or platform. They do not explain how, but why. If you feel compelled to clean house on your bookshelf every five years, trust me on this, you're buying the wrong programming books.

I wouldn't trade my programming bookshelf for anything. I refer to it all the time. In fact, I referred to it twice while composing this very post.

I won't belabor my recommended reading list, as I've kept it proudly the same for years.

(Update: Tim Spalding kindly set up a LibraryThing account on my behalf – and members have already documented and entered every book pictured on these shelves. Impressive, and quite cool!)

But I do have this call to arms: my top five programming books every working programmer should own – and read. These seminal books are richly practical reads, year after year, no matter what kind of programming I'm doing. They reward repeated readings, offering deeper and more penetrating insights into software engineering every time I return to them, armed with a few more years of experience under my belt. If you haven't read these books, what are you waiting for?

Code Complete 2	Don't Make Me Think
Peopleware	Pragmatic Programmer
Facts and Fallacies

It is my greatest intention to make stackoverflow.com highly complementary to these sorts of timeless, classic programming books. It is in no way, shape, or form meant as a replacement for them.

On the other hand, if you're the unfortunate author of Perl for Dummies, then watch your back, because we're definitely gunning for you.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++


- Bloggery committed by chris tower - 1908.03 - 10:10

- Days ago = 1491 days ago

- New note - On 1807.06, I ceased daily transmission of my Hey Mom feature after three years of daily conversations. I plan to continue Hey Mom posts at least twice per week but will continue to post the days since ("Days Ago") count on my blog each day. The blog entry numbering in the title has changed to reflect total Sense of Doubt posts since I began the blog on 0705.04, which include Hey Mom posts, Daily Bowie posts, and Sense of Doubt posts. Hey Mom posts will still be numbered sequentially. New Hey Mom posts will use the same format as all the other Hey Mom posts; all other posts will feature this format seen here.