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.
Wouldn't that apply to git? You can probably get 90-95% of the benefit of git using mercurial with a fraction of the effort in learning. Life is too short to spend learning the internals of one version control system.
This idea of "Don't waste time on X focus on more valuable Y" has no real end. Don't waste your non-work time on learning computing related stuff and instead spend time on social connections and physical fitness first. Pays off way more than emacs, git, vim, lisp, or programming paradigms. See how easy it is to make such pronouncements?
> You can probably get 90-95% of the benefit of git using mercurial with a fraction of the effort in learning.
You absolutely cannot.
Even if we pretend that Mercurial is simply outright better than Git, there's a lot of value in learning Git specifically, as it's what most development teams use. Employers value proficiency in Git. If you mention your Mercurial proficiency in an interview, it's likely to be scored up as cute but irrelevant.
If you always work alone, sure, Mercurial might work great for you, but the real value of these version-control systems is in enabling teams to work effectively. Most teams these days use Git, so you need to know Git.
(Of course, if your team does use Mercurial, you'd better become proficient in Mercurial.)
> Life is too short to spend learning the internals of one version control system.
I agree that learning the intimate internals of Git's codebase isn't something that's likely to pay off in the day job, but short of that, Git's 'useful skill-ceiling' is pretty high.
> Don't waste your non-work time on learning computing related stuff and instead spend time on social connections and physical fitness first.
Depends on your working situation. If your work offers no opportunity to learn new skills, and you don't want your CV to get stale, you have little choice.
>there's a lot of value in learning Git specifically, as it's what most development teams use. Employers value proficiency in Git. If you mention your Mercurial proficiency in an interview, it's likely to be scored up as cute but irrelevant.
Given that the person I was responding to was advocating not spending time on things for the reason that employers are looking for them, and is advocating things almost no workplace uses, I find your comment strange. Perhaps you should be responding to the comment I'm responding to?
>Depends on your working situation. If your work offers no opportunity to learn new skills, and you don't want your CV to get stale, you have little choice.
You do have a choice, and you made your choice. In the US, in this era, SW professionals are near the top when it comes to freedom to change jobs and change locations. When I know several people who make half of what I do, are relatively unskilled, and have to work much longer hours than I do, who made a very clear choice in favor of physical fitness and social relations, I am not going to claim I don't have a choice.
Having said that, this is all orthogonal to my point, which was how easy it is to make (reasonable) lists of things one should focus on that are almost exclusive to one another.
After programming for 50 years and having a successful career, I’m not really going to need serious git skills. I still write code, all the time, but it’s for fun and personal projects.
Yes Mercurial is easier to use than git, and really fossil is even better for me, someone that works solo. However git is what I use. I know that if I am going to help someone with source code control (like my daughter who is studying CS) git is what they will need help with. Personal use of git is to me the only way to ensure that I can give pertinent help.
> Wouldn't that apply to git? You can probably get 90-95% of the benefit of git using mercurial with a fraction of the effort in learning. Life is too short to spend learning the internals of one version control system.
I haven't used mercurial much, but it seems like you would have to understand the same amount about the core data structures to do something in mercurial as with git [0]. The really simple activities you do day to day don't require any deep knowledge. And when you want to do more complicated things you have to know what you are doing.
Its similar to writing simple C++ programs vs complex ones. You may not need to understand smart pointers to write small programs, but understanding smart pointers or at least the concepts behind them is critical to write large programs.
[0]: There are minor differences between the two that probably make git harder to pick up. Among them being the staging area, and rather obtuse UI. However, the market effects of git are hard to ignore.
Social connections and physical health are also such multipliers, just as vim or git or lisp. If you have been asocial and unhealthy in the past and now were able to change you will also experience this increase in output, e.g. because you can suddenly ask others for help and can focus for longer periods of time. Maybe you will even come into less situations where you use git and vim and programming languages, because others also value your ability to focus and your connections more than your ability to produce code. Then it paid of even more to focus on these multipliers. Great.
That doesn't mean either of the other multipliers are not multipliers though. They are just more topic-focussed instead of generally applicable.
And no, mercurial can't do more than 5% of what git can. That's just a fact. Just like you probably wouldn't waste time explaining a flat earther why the earth is round I won't explain this to you. If you are smart (and I assume so from your comment) you will go out and fact check that by yourself from the assumption that you just might be mistaken and maybe this random dude on the net might've been correct.
Hope I'm right in that assumption. Then you'll have an awesome time of a lot of WOWs ahead of you. Enjoy it.
And if not, there's not much lost. Some humans will fly to Mars even if some others believe the Earth is a disk.
One thing that life tought me is that you can be the best dev in the company but still your boss is going to give the promotion to one of his buddies he likes.
Personal connections and social engineering is 10times as important as your actual skills.
Its unfortunate looking at current state of the world, but thats how it simply is. And I understand some may not agree with it, but please look around yourself and tell me Im wrong..
While it's nice you're agreeing with me, I did not suggest it as a way to improve your career, and my advice stands even if it has no chance of helping your career.
>If you are smart (and I assume so from your comment) you will go out and fact check that
Exactly how do I fact check this? Most Google searches give two types of results: Either pro git or meh they're mostly the same. Virtually every pro git page has basic facts wrong about mercurial and are criticizing the mercurial of a decade or longer ago(0) The very few exceptions cover use cases that really do fall into the 5% category.
And I assume you meant 95% and not 5% that you wrote. If you really did mean the latter I suspect you know little of mercurial.
(0) Branches are a classic example. Although I do think git has slightly better branch handling pretty much most pages criticizing mercurial branches expose their ignorance of beaching in mercurial
I'd argue they got it right: when 95% of projects use Git, then why learn anything else? I think the last time I used Mercurial was almost a decade ago at this point, and I don't know of any major project that uses it (outside of Mozilla, who has most of their newer projects are on GitHub, and OpenJDK, which maintains a GitHub mirror).
That is ignoring my point with a deflection. This isn’t 1999 with Linux as a (relative) newcomer and on the upswing, the adoption rate has clearly dropped over time. I did miss the fact that Facebook uses Mercurial internally, but their public-facing repos are all on Github (including, ironically, their re-implementation of Mercurial, Mononoke). Open Source software doesn’t exist in a vacuum, it needs a community to support it and use it.
All sorts, but I believe it was born out of frustration at unnecessary complexity arising from standard enterprise development.
Hickey’s choice of hosting it on the JVM was ingenious, gives access to one of the largest most battle tested ecosystems in modern day enterprise engineering.
It’s much more versatile these days with the likes of ClojureScript, it’s being used in anything from real-time multimedia projects to SPA JavaScript work.
Basically anything other than operating systems. I've been working on an optimizing compiler for spreadsheets, and an event sourcing system with a WebSocket gateway in my current work.
Great to read that. I also know one other person who writes Clojure professionally. Gives clojure to some of who hoped for people to get this opportunity at some point.
There are also rock stars, but that doesn't mean we should give advise that anyone could become a rock star. Those who will become rock stars will become it anyway even if you tell them they won't.
I code in lisp for work everyday! This is a bad promise, but I agree lisp is amazing. I've recently been learning to love macros and reading let over lambda is fantastic!
While I agree in principle, this is a nice way to quickly become unemployed.
We live in a hype oriented industry, where momentum and programmer enthusiasm (free man hours or work) and not technical merits predict whether a given technology will thrive or not.
> Don't learn the hippest UI IDE, learn vim or emacs.
This jars. Why not recommend really learning Cocoa and AppleScript or VB for Applications? Or really dig into Smalltalk's code browser? vi and emacs have a long track record, and I still use both because I sank the time in to learn them years ago, but I wouldn't recommend them as fundamentally changing someone's view of computing.
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.
Although I have some duds, the hundreds of pages of wiki contributions I've made are nearly all designed to be what I wished existed when I was learning said details. Sadly, they only help to a certain degree. The individual really needs to want to learn to get any real lasting benefit.
>what I wished existed when I was learning said details.
This isn't what 'pedagogical focus' means though. Just writing down the stuff that helped you out very rarely covers what is necessary to help people out in general.
A pedagogically focused approach would also cover the assumptions you had going in and provide clear references to expected prerequisites. It should also cover the "why" for a specific approach if there are multiple approaches, which is very frequently left out of internal documentation wikis.
I hate these books. Basically it's just synonyms for well known concepts, like blue in language b is called gog and orange in language a is called koom. It extends to more complex concepts as well like this is how you do an if statement in python vs. c++. For JavaScript the good parts it's this type of book. Literally nothing new is learned save how to rename the some concept as the good part of JavaScript. Details that you can learn any time.
What I want from a book is to learn new concepts. For example functions and data are the same thing. Or recursion and a loop + stack are isomorphic concepts. Or that unit tests only verify one test case of your program correct while a proof based systems like type checking can verify an entire domain of your program correct.
If you want innovative mind bending concepts read a book about Lisp. Paul Graham's "On Lisp" is great - and I've heard good things about "Let over Lambda".
Lisp is such and open mental playground when it comes to programming.
Vs the languages which consist of the exact same ideas with a slightly different syntax.
I went that route, and found it less bang for the buck.
Still interesting, but a lot of learn, but it took significantly more effort to see any type of reward. And the total reward is definitely less than that of lisp (from what I encountered).
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.
That was a comment I read some time ago coming from Umberto Eco. He has a very big library and he occasionally gets asked by visitors to his home if he read all or most of them? His answer was long your lines. Of course he had not read most of it at all - because what was the point of keeping a library mostly consisting of books you already read? Your library should be the exact opposite to be useful, i.e. mostly consisting of books you had not yet read. Unfortunately I forgot where I read that.
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.
I'm describing the problem of already owning books you'd like (love!) to read, but don't make time for them.
I'm also describing that most of us (I posit) already have a great collection of great books, which aren't fully tapped. Honestly, even re-reading your college textbooks will up your level significantly. You don't usually need to seek out the "best of the best" book, unless you're really going deep or want to learn a specific topic in a very particular way.
If you say so, fair enough. The image you've picked seems like a perfect encapsulation of a different problem. I want to help the person with the smooth-spined G.E.B whose third monitor is not quite at the right height. Go right ahead and slip it under there.
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.
If you can convince your lead to let you set aside some time to update it / write a new one, it's a good opportunity to learn AND earn some brownie points
My personal experience is that no discipline is better at pointing out my weak spots than trying to write instructions or otherwise document something.
If I'm understanding your comment right, you could use Calibre to do this just as easily, possibly with more information. There's no requirement to actually have a file associated with a record in Calibre, so you can add your comments into the metadata (or have the record point to a file with comments and notes instead of/alongside the ebook). I use a Calibre database to keep track of my bookshelves; the metadata includes ISBN, my review, my rating, average online rating from various sites, where I got the book, similar and associated books, etc. It should be relatively simple to get a single-click plugin going that brings up a search for the ($ISBN|$ASIN|$TITLE+$AUTHOR) of the currently selected record. The only thing missing here is public access (the buying gifts part)
While I myself would like to do just this at some point, this is a lot of work to learn a new tool vs using a website that someone is already familiar with. And you get the added bonus of it being in the cloud and available on your phone (especially great for trips to used bookstores).
Note that I'm not endorsing using this for "flipping" books, quite the opposite. I've been screwed over so many times in my search for old out-of-print technical books, that it's a bit of a sore spot.
I remember begging my mom to buy me GEB at a Barnes and Noble when I was about 17, about twenty years ago. The book was expensive, especially for a Mexican family, but the book was hyped up in Slashdot, so I really really wanted to read it. I remember reading a few chapters and then couldn't muster the motivation to continue.
I still feel guilty about it. The book sits in my bookshelf, spine unbroken. My mom recently passed away. I'm sorry, mom.
Libraries: I ordered it thru the library maybe ten years ago after geeks talked it up on a similar site. Gave up after a few chapters, had no clue what it was about.
GEB was written when he was a young man and his ideas hadn't fully percolated into the more concrete form they take in I Am a Strange Loop. I can't find a source at the moment (it might actually be in IaaSL itself) but I seem to remember him saying IaaSL is the book he wanted to write when he wrote GEB.
Both are excellent reads, but I'd definitely agree IaaSL is far more approachable and a better use of your time.
I Am a Strange Loop spends an entire chapter of Hofstadter informing us how he is better than everyone else because he hears Bach better than everyone else. And this attitude fills the book, I found it very obnoxious and am not sure why no else mentions it.
There are at least two places in the book where he talks about an interesting point, then realizes it is a rehash of something from a previous book. And aside from the self-congratulations (did you know being a vegetarian makes you more of a person?), anything interesting in this book was done better in a previous book.
I would recommend The Mind's I instead. It's a collection of stories and essays from most of his influences, see what Turing, Lucas, et al. actually said.
He also spends a chapter trashing Searle, in a way that seems a little unnecessarily vindictive.
I still enjoyed it. It's not for everyone, but I found that his meanderings served to break up the seriousness of the subject in a way that made for an easy read, much easier than GEB.
if you read one book of hofstadter's, make it "metamagical themas", a truly engaging collection of his columns for "scientific american". I also liked "le ton beau de marot", on the art of translation, but that's less of a general appeal book.
I have read geb, and it had some nice ideas, but i can't say I was motivated to reread it; it felt overly self indulgent somewhat in the manner of a friend telling you about how their rpg campaign played out without realising that half the interest lay in having been there.
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.
There’s a used book store near where I work that has a whole section of programming books. I stop by and pick up old computer books for $10 from time to time, and I always mean to get around to actually reading them - more than once I’ve found that I bought the same book twice, having forgotten that I already own it…
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.
* 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.