These reading lists are lovely and promise a Better You, but I'll propose the following challenge:
* If you're at home, turn around and look at the bookshelf you've already accumulated. Did you really read all those books you so looked forward to when you first bought them? Or do you remember all the best bits from your favorite ones? Be honest now... the unbroken spine on your Godel Escher Bach suggests otherwise. Read what you have, before stressing on Kay's or others' lists!
* If you're at work, have you read all the wiki/docs/etc created by your team and neighboring teams? Do you understand the full architecture and implementation of the system you work with every day? Go read that, level up and become the most knowledgeable person on your team.
Sadly 99% of the code that's written nowadays can be directly thrown away. I propose another challenge: Learn the actual meaningful stuff. E.g. how to code in lisp. Really learn it. You will never code lisp in your job. Promised. But in almost every task you will find that you reuse what you learned.
Or learn the architecture of git. How many people write bullshit around git because they don't understand that git can already do 100x of what their shell script or UI tool or plugin can do....
Don't waste your time with what is hip and instead learn how things really work. Real things. Don't learn the latest javascript framework, but learn the difference between class based inheritance and prototypal inheritance. Don't learn the hippest UI IDE, learn vim or emacs. Really learn it, e.g. how to solve almost all problems in vim without any plugins.
And one last point about "read all the content your team created". Not sure how big your teams are, but in many companies that's impossible. If you spend 12h of reading 7 days a week you can't read all the content that is created in that week. But you know that the cool_library that replaces the AwesomeLibrary is just as bad at solving the problem and both actually don't even know what the problem is.
I've read most of it, some parts several times, over the years.
But my spine is unbroken. Here's how:
Open about 20 pages and run your finger firmly down the gutter. Flip 20 pages and repeat until you get to the center of the book. Next, start at the back and repeat, moving towards the center. Then repeat the whole exercise.
While you are reading, occasionally run your finger down the gutter. If you do this, you'll never break a spine, and those massive paperbacks will lie open on the table.
An iPhone makes a good book weight, almost as good as Levenger's.
To the contrary, some of the best books have so much knowledge in them that you instantly level-up many notches with a single chapter.
For instance, reading The Pragmatic Programmer and JavaScript: The Good Parts early-on changed my professional life irrevocably, both in terms of programming and career.
I am sure there are various other books like those that truly are impactful, and it doesn't hurt to look up recommendations for those from people who are experts / polymaths.
The case against wikis (with the exception of design docs) and blog posts is that they are erratic, restricted, unedited, stale, and low on pedagogical focus. Some of the books are meticulously structured-- there's no comparison.
The purpose of a personal library is not necessarily to keep all the books you've already read within hands reach. I personally prefer to keep books I have never read but may one day be interested to read, so when I approach the bookshelves, it has the potential of a surprise, the thrill of exploring/discovering/etc.
Ouch. This hurts. This is my problem exactly. I have two bookshelves full of programming books that I’ve never completed, and yet each morning I spend at least 30 minutes on Amazon reading the TOC of whatever new programming books they’re recommending to me. Imagine if I instead spent that time reading the books I already have. Just simple math shows that would be 180+ hours of learning per year. But my biggest problem is simply deciding where to begin. Which book do I read? As silly as it sounds, that is very often exactly what paralyzes me. I struggle to just pick one and commit to it.
the unbroken spine on your Godel Escher Bach suggests otherwise. Read what you have, before stressing on Kay's or others' lists!
Read what you like. You're describing someone who's clearly been 'stressing lists' so much they've got books they're not interested in and are never going to read. If you've made the mistake of accumulating a bunch of books as props, well, it happens - there's no need to compound this further by guilt-tripping yourself to read them before reading something you might actually want to read.
Even ignoring the fact that people are more than just cogs in their company's grinder, I don't quite get why you seem to believe it is obviously more important to memorise the method signature of my interns' implementation of leftpad() than what a good book has to offer.
To be entirely honest, the list is actually too narrowly focussed to support my larger point: namely, that lifting you view to the horizon, by sampling from the best that fields as far away from yours as possible have to offer, is about feeding the soul and not just the machine.
Anyway, I've only read about half the books on my bookshelf (but including GED) and that's actually how I like it. After all, books you haven't read are worth far more to you than those you already know.
Had it been a reading list from anyone else I may not have looked as I feel as fatigued as your statement suggest you are as well(and you are very much talking about my bookshelf as well)...
But there is a special place in my heart for certain folks...Alan Kay is one of em. Time to move some of that dust on my shelf around.
I don't think there's anything wrong with buying books that you intend to read in the future. I do this all the time, and when I want something new to read I pick something off of the shelf. There are worse things to buy than books.
I have GEB in the bookshelf behind me and have read it all the way through, same for The Mind's I, two of the books in the list are there as well. The one book behind me that I haven't finished is the dragon compilers book by Aho, Sethi & Ullman.
Have also read Lisp 1.5 but don't have a physical copy.
The depressing things about reading lists is that it's hard to go through all of them. Many of the books list (SICP) take a long time to wade through, read, and program the examples. They are not "light reading".
You don’t have to read 100% of every single book. Even just going through the first few chapters of SICP (or other similarly dense, more theoretical text) would most likely be beneficial to those who have never worked through the material before.
I have read "Lisp 1.5 Programmers Manual”, “The Mythical Man-Month” and “The Meta-Object Protocol” by Kiczales. These all are definitely timeless classics.
"In Lisp, if you want to do aspect-oriented programming, you just do a
bunch of macros and you're there. In Java, you have to get Gregor
Kiczales to go out and start a new company, taking months and years
and try to get that to work. Lisp still has the advantage there, it's
just a question of people wanting that." -- Peter Norvig
"I am reminded of Gregor Kiczales at ILC 2003 displaying some AspectJ to a silent crowd, pausing, then plaintively adding, "When I show that to Java programmers they stand up and cheer." -- Kenny Tilton
Does anyone else get scared that too much breadth will stifle them? CS is a massive field these days and you could easily sink all your time into a small area without fully mastering it. I have had coworkers before and who could speak at length about different Linux distros, networking, web dev, dbs etc. but then were not great at the meat and potatos of the job.
The books recommended by Kay here are very much about DEPTH, not BREADTH.
The majority of programming books are just ephemera and arcana and details that will be irrelevant in a year, or next month when the new version of the framework comes out.
Kay points to books, like the original Lisp Programming Manual, that will help you understand deep core concepts about computing itself, that will remain applicable no matter what framework or library you need to use tomorrow.
Take an Alan Kay, a McCarthy, Norvig, Abelson, Sussman, Armstrong, Steele, etc. from their prime and drop them into a software company where they have zero familiarity with the programming languages or tools currently being used, and within days or weeks they will be the most productive developer at that company by far. They will come up with simple, elegant, high performance and correct solutions to problems none of the other developers would have even considered.
Those are the kinds of thinkers you want to emulate, if you really want to write excellent software solving real problems in the shortest amount of time.
I disagree with the premise itself. Breadth of knowledge is not obtained because you will use every single piece of it, rather because you will be able to make connections between disparate topics. When you have breadth of knowledge you know which reference to pick up for help with your new exciting problem. (I am assuming it is a given that breadth of knowledge does not imply only superficial knowledge).
Lastly, having breadth of knowledge means you have learned how to learn efficiently. This is a significant force multiplayer.
My own humble suggestions - although the books are hardly forgotten. But I think people focus a lot on technical / engineering books, and very little on design / user experience / human behavior, which arguably contribute much more to the overall impressions end users have of programmers' work.
First, the greatest book of all time, The Autobiography of Benjamin Franklin - an amazingly introspective and insightful look into how to live an examined life and improve oneself.
And then if you want to learn lower-case "design thinking", my top 10 books
* Design for Everyday Things - duh. I re-read chunks of it all the time.
* Tufte - hard to pick one, I might actually be iconoclastic and go with Visual Explanations which I think has more to offer programmers over pure data visualization. Again, just grab one every day, flip through 3-4 pages, rinse, repeat.
* User Story Mapping - Extremely memorable book - it gives you a pretty clear field guide on prioritization, empathy, communication ... just a great book.
* Badass by Kathy Sierra - I flip through this book again and again. It is gospel truth about what motivates humans.
* The Field Guide to Human-Centered Design - IDEO's most practical book. (Close second: Designing Interactions.)
* Universal Methods of Design - another deeply practical book, lots of good tips and examples.
* Universal Principles of Design - Sister book to the Universal Methods. Again, straightforward, flip to any page and get an idea when you're brainstorming.
* Thinking in Systems - I recommend you skim this book through, but come back to it a lot, it grows with you.
* Inspired by Marty Cagan - again, love nuts and bolts process books.
* Don't Make Me Think! - still a classic, still see these mistakes being made all the time in modern app dev.
Joe Amstrong had a related talk 'A Guide for the Perplexed'[0] last year. He mentioned several 'forgotten great ideas' such as Linda Tuple Spaces, Flow-based programming, Xanadu and Unix pipes.
Coming from Alan Kay i definitely need to check these out. If I'd read this post a year ago I would have known almost none of the authors, but after reading "Hackers: the heroes of the computer revolution" earlier, these are all names that stood out right away.
Both Minsky and McCarthy seem like almost mythical figures in the book, and I don't think I could ever hold aa candle to them, but the next best thing is probably to understand their thinking. I think it's a bit easy for us to get caught up in the medium blog posts detailing a small segment of a new framework, when what we really ought to do to grow, is go back to the basics and understand them in-depth.
> The way to grow from this book is to deeply learn what they did and how they did it, and then try to rewrite page 13 in a number of ways. How nicely can this be written in “a lisp” using recursion. How nicely can this be written without recursion? (In both cases, look ahead in the book to see that Lisp 1.5 had gotten to the idea of EXPRs and FEXPRs (functions which don’t eval their arguments before the call — thus they can be used to replace all the “special forms” — do a Lisp made from FEXPRs and get the rest by definition, etc.).
Found it ironic that in a comment about Lisp, Kay forgot to balance his parens. :)
I love that Joe Armstrong's PhD thesis is on this list. I have it on my reading list for junior engineers. It's incredibly accessible and the mental model is very powerful.
This is a great companion to "The Goal" and "The Phoenix Project," both of which use fictional narratives to illustrate best engineering practices in the context of saving a (fictional) business.
I'd also like to point out that the majority of software engineers nowadays lacks the mathematical background, so it's probably worth including theoretical books like Abstract Algebra by Dummit and Foote on the 'must read' list.
Alan kay is a big of Engelbart and I'm surprised it wasn't listed in his answer. Also, for anyone that's interested, a windows clone of NLS is available here for windows: http://www.ndma.com/resources/ndm8543.htm
Minus the "journal", many of the multi-user capabilities, and the "compiler compiler" programming system of NLS. still, it's interesting to play with.
[+] [-] khazhou|6 years ago|reply
* If you're at home, turn around and look at the bookshelf you've already accumulated. Did you really read all those books you so looked forward to when you first bought them? Or do you remember all the best bits from your favorite ones? Be honest now... the unbroken spine on your Godel Escher Bach suggests otherwise. Read what you have, before stressing on Kay's or others' lists!
* If you're at work, have you read all the wiki/docs/etc created by your team and neighboring teams? Do you understand the full architecture and implementation of the system you work with every day? Go read that, level up and become the most knowledgeable person on your team.
[+] [-] narnianal|6 years ago|reply
Or learn the architecture of git. How many people write bullshit around git because they don't understand that git can already do 100x of what their shell script or UI tool or plugin can do....
Don't waste your time with what is hip and instead learn how things really work. Real things. Don't learn the latest javascript framework, but learn the difference between class based inheritance and prototypal inheritance. Don't learn the hippest UI IDE, learn vim or emacs. Really learn it, e.g. how to solve almost all problems in vim without any plugins.
And one last point about "read all the content your team created". Not sure how big your teams are, but in many companies that's impossible. If you spend 12h of reading 7 days a week you can't read all the content that is created in that week. But you know that the cool_library that replaces the AwesomeLibrary is just as bad at solving the problem and both actually don't even know what the problem is.
[+] [-] wrycoder|6 years ago|reply
I've read most of it, some parts several times, over the years.
But my spine is unbroken. Here's how:
Open about 20 pages and run your finger firmly down the gutter. Flip 20 pages and repeat until you get to the center of the book. Next, start at the back and repeat, moving towards the center. Then repeat the whole exercise.
While you are reading, occasionally run your finger down the gutter. If you do this, you'll never break a spine, and those massive paperbacks will lie open on the table.
An iPhone makes a good book weight, almost as good as Levenger's.
[+] [-] ignoramous|6 years ago|reply
For instance, reading The Pragmatic Programmer and JavaScript: The Good Parts early-on changed my professional life irrevocably, both in terms of programming and career.
I am sure there are various other books like those that truly are impactful, and it doesn't hurt to look up recommendations for those from people who are experts / polymaths.
The case against wikis (with the exception of design docs) and blog posts is that they are erratic, restricted, unedited, stale, and low on pedagogical focus. Some of the books are meticulously structured-- there's no comparison.
[+] [-] new2628|6 years ago|reply
[+] [-] ExtremisAndy|6 years ago|reply
[+] [-] pvg|6 years ago|reply
Read what you like. You're describing someone who's clearly been 'stressing lists' so much they've got books they're not interested in and are never going to read. If you've made the mistake of accumulating a bunch of books as props, well, it happens - there's no need to compound this further by guilt-tripping yourself to read them before reading something you might actually want to read.
[+] [-] IfOnlyYouKnew|6 years ago|reply
To be entirely honest, the list is actually too narrowly focussed to support my larger point: namely, that lifting you view to the horizon, by sampling from the best that fields as far away from yours as possible have to offer, is about feeding the soul and not just the machine.
Anyway, I've only read about half the books on my bookshelf (but including GED) and that's actually how I like it. After all, books you haven't read are worth far more to you than those you already know.
[+] [-] commandlinefan|6 years ago|reply
Well, in my defense, it's pretty terribly written...
[+] [-] kristopolous|6 years ago|reply
The Amazon wishlist has honestly helped me a lot here, I can also annotate and sort it in case I come across a book again.
Plus it helps people buy gifts for me on holidays really easily.
Sorry for turning this into an Amazon ad but it's a great feature
[+] [-] msla|6 years ago|reply
I find it amusing that this book is chosen as an example of one people don't really read, and not, say, Penrose's The Road To Reality.
[+] [-] _57jb|6 years ago|reply
But there is a special place in my heart for certain folks...Alan Kay is one of em. Time to move some of that dust on my shelf around.
[+] [-] shawnps|6 years ago|reply
[+] [-] el_benhameen|6 years ago|reply
So accurate as to be creepy. There's a shelf full of unread technical books right behind me. I will save this link for later.
[+] [-] Waterluvian|6 years ago|reply
The act of figuring out what's next and buying the materials feels good without any commitment.
[+] [-] elwell|6 years ago|reply
This hits close to home!
[+] [-] astatine|6 years ago|reply
Ouch. That hurt. I literally turned around and saw this book in pristine condition.
[+] [-] pnathan|6 years ago|reply
also you can unload poor books that are taking up space now!
[+] [-] rjsw|6 years ago|reply
Have also read Lisp 1.5 but don't have a physical copy.
[+] [-] unknown|6 years ago|reply
[deleted]
[+] [-] JakeStone|6 years ago|reply
[+] [-] m463|6 years ago|reply
[+] [-] tonyedgecombe|6 years ago|reply
[+] [-] bigred100|6 years ago|reply
[+] [-] steveeq1|6 years ago|reply
alan kay is a big fan of his.
The depressing things about reading lists is that it's hard to go through all of them. Many of the books list (SICP) take a long time to wade through, read, and program the examples. They are not "light reading".
[+] [-] HiroshiSan|6 years ago|reply
[+] [-] nickloewen|6 years ago|reply
That gist is copied from this page on Victor's site: http://worrydream.com/#!/Links
It was discussed on HN in 2014: https://news.ycombinator.com/item?id=7578795
[+] [-] GuiA|6 years ago|reply
[+] [-] newsreview1|6 years ago|reply
[+] [-] nabla9|6 years ago|reply
These quotes about Gregor Kiczales and AspectJ https://en.wikipedia.org/wiki/AspectJ are good intro to MOP:
"In Lisp, if you want to do aspect-oriented programming, you just do a bunch of macros and you're there. In Java, you have to get Gregor Kiczales to go out and start a new company, taking months and years and try to get that to work. Lisp still has the advantage there, it's just a question of people wanting that." -- Peter Norvig
"I am reminded of Gregor Kiczales at ILC 2003 displaying some AspectJ to a silent crowd, pausing, then plaintively adding, "When I show that to Java programmers they stand up and cheer." -- Kenny Tilton
[+] [-] ericmcer|6 years ago|reply
[+] [-] jimbokun|6 years ago|reply
The majority of programming books are just ephemera and arcana and details that will be irrelevant in a year, or next month when the new version of the framework comes out.
Kay points to books, like the original Lisp Programming Manual, that will help you understand deep core concepts about computing itself, that will remain applicable no matter what framework or library you need to use tomorrow.
Take an Alan Kay, a McCarthy, Norvig, Abelson, Sussman, Armstrong, Steele, etc. from their prime and drop them into a software company where they have zero familiarity with the programming languages or tools currently being used, and within days or weeks they will be the most productive developer at that company by far. They will come up with simple, elegant, high performance and correct solutions to problems none of the other developers would have even considered.
Those are the kinds of thinkers you want to emulate, if you really want to write excellent software solving real problems in the shortest amount of time.
[+] [-] krastanov|6 years ago|reply
Lastly, having breadth of knowledge means you have learned how to learn efficiently. This is a significant force multiplayer.
[+] [-] AlexeyBrin|6 years ago|reply
http://www.softwarepreservation.org/projects/LISP/book/LISP%...
[+] [-] kthejoker2|6 years ago|reply
First, the greatest book of all time, The Autobiography of Benjamin Franklin - an amazingly introspective and insightful look into how to live an examined life and improve oneself.
And then if you want to learn lower-case "design thinking", my top 10 books
* Design for Everyday Things - duh. I re-read chunks of it all the time.
* Tufte - hard to pick one, I might actually be iconoclastic and go with Visual Explanations which I think has more to offer programmers over pure data visualization. Again, just grab one every day, flip through 3-4 pages, rinse, repeat.
* User Story Mapping - Extremely memorable book - it gives you a pretty clear field guide on prioritization, empathy, communication ... just a great book.
* Badass by Kathy Sierra - I flip through this book again and again. It is gospel truth about what motivates humans.
* The Field Guide to Human-Centered Design - IDEO's most practical book. (Close second: Designing Interactions.)
* Universal Methods of Design - another deeply practical book, lots of good tips and examples.
* Universal Principles of Design - Sister book to the Universal Methods. Again, straightforward, flip to any page and get an idea when you're brainstorming.
* Thinking in Systems - I recommend you skim this book through, but come back to it a lot, it grows with you.
* Inspired by Marty Cagan - again, love nuts and bolts process books.
* Don't Make Me Think! - still a classic, still see these mistakes being made all the time in modern app dev.
[+] [-] namelosw|6 years ago|reply
[0] https://youtu.be/rmueBVrLKcY?t=1949
[+] [-] DonHopkins|6 years ago|reply
http://thinking-forth.sourceforge.net/
[+] [-] NegatioN|6 years ago|reply
Both Minsky and McCarthy seem like almost mythical figures in the book, and I don't think I could ever hold aa candle to them, but the next best thing is probably to understand their thinking. I think it's a bit easy for us to get caught up in the medium blog posts detailing a small segment of a new framework, when what we really ought to do to grow, is go back to the basics and understand them in-depth.
[+] [-] mcaruso|6 years ago|reply
Found it ironic that in a comment about Lisp, Kay forgot to balance his parens. :)
[+] [-] EdwardCoffin|6 years ago|reply
[+] [-] aj7|6 years ago|reply
[+] [-] sg0|6 years ago|reply
[+] [-] deepaksurti|6 years ago|reply
More Lisp fun [2].
[1] http://www.softwarepreservation.org/projects/LISP/book/LISP%...
[2] http://www.softwarepreservation.org/projects/LISP
[+] [-] numbsafari|6 years ago|reply
[+] [-] doc_gunthrop|6 years ago|reply
[+] [-] teachrdan|6 years ago|reply
https://www.amazon.com/Goal-Process-Ongoing-Improvement/dp/0...
https://www.amazon.com/Phoenix-Project-DevOps-Helping-Busine...
[+] [-] higherkinded|6 years ago|reply
[+] [-] minsight|6 years ago|reply
http://www.ibm-1401.info/Meta-II-schorre.pdf
[+] [-] steveeq1|6 years ago|reply
Alan kay is a big of Engelbart and I'm surprised it wasn't listed in his answer. Also, for anyone that's interested, a windows clone of NLS is available here for windows: http://www.ndma.com/resources/ndm8543.htm
Minus the "journal", many of the multi-user capabilities, and the "compiler compiler" programming system of NLS. still, it's interesting to play with.
[+] [-] postit|6 years ago|reply