6 ms·

This is more reading material than some Master's programmes. Here's a shorter alternative: Choose a few languages, play with them for a few months, get to the

This is more reading material than some Master's programmes. Here's a shorter alternative: Choose a few languages, play with them for a few months, get to the point where you can write some idiomatic code. Focus on SOLID code and what that means idiomatically in those languages. Learn strengths and weaknesses of each. It's never enough to just learn one language, I think, in the same way no good musician should only ever learn one genre. Do you really want to be like the woman in the bar in Blues Brothers ("We do both types of music, Country and Western")? Learn how to debug and profile. Ideally, learn how to write automated performance tests (along with unit and integration tests) that run on every build so you can keep track of what's going on for those critical pieces. Don't aim for 100% test coverage, aim for enough coverage to help you catch yourself from regressing working code. Learn just enough git to create a repo, create branches, push and merge, and all that. Anything more complex? Google it when you need to like the rest of us. Now go build something. Want to do something with chat? Sure, go read up on IRC and XMPP and Signal and Wire and all that. Want to do something with email? Sure, go read the RFCs and scramble around that area. Interested in UX? Go and read guidelines for your favourite app store and do that, even if you never plan to submit there: it's good advice. The idea of reading 110+ books first in the hope you'll then start your epic hack sounds to me like epic procrastination. Here is one of the most iconic pages from punk history: https://static.guim.co.uk/sys-images/Guardian/Pix/pictures/2012/5/23/1337810776607/sideburns940.jpg https://static.guim.co.uk/sys-images/Guardian/Pix/pictures/2... Code is punk. Go start a band.

rootlocus 9y ago
> Learn just enough git to create a repo, create branches, push and merge, and all that. Anything more complex? Google it when you need to like the rest of us. Bad advice. Learning git internals is surprisingly easy and has a lot of ROI. This tiny book has everything you need https://github.com/pluralsight/git-internals-pdf https://github.com/pluralsight/git-internals-pdf
- yellow_postit 9y ago
  What's the ROI? I tend to agree with the author on this subject here. In my case I care for just enough git to get by so I can focus on the projects I'm using git to facilitate.
  - rootlocus 9y ago
    Learning "recipes" on the internet and copy pasting commands is a sure way to mess something up and could bring a lot of frustration. You only need to spend a few hours to understand how git works underneath to avoid any of that.
    - ptero 9y ago
      You should not have to learn the internals of any decent source control system to use it in a way that does not lead to a mess. An overview of usage principles and examples should be enough and should provide enough insight to search for more information if needed. User level documentation should be sufficient for user actions. If someone wants to learn internals, great; but this should be an option, not a requirement.
      - rootlocus 9y ago
        Lots of "should"s, but we're talking about advice on using git, not "any decent source control system". This is a problem I see with people not understanding git. They treat it like they think it should be treated. Like it or not, that's not going to work for git. You don't give python advice to a C++ developer, regardless of how much you'd like C++ to be like python.
        taeric 9y ago
        This logic also works on computers. Or, well, anything. You'd be surprised at just how useful people can find things while still making a mess of them. So, yes, if you have the time, learn the internals. But no, that is not in any way a prerequisite. Nor should it be.
- trentmb 9y ago
  Just use fossil.
dualogy 9y ago
To quote: This list is basically a curriculum for decades of learning about the wonders of computers --- now "decades" would rather suggest that they not be perused as a full-time occupation. To your point: mostly agree, but for anyone who lives and breathes your spirit, a collection of 110+ books isn't a dangerous distraction but a welcome enriching augmentation. After some hours of coding the brain demands, deserves, benefits from --- a break. Every couple of weeks, a full day or 3. After some months, even a full week. My point? I noticed that even reading "books that deep -dive into interesting technical topics" is recreational and leisurely compared to high-intensity coding (different brain areas get stimulated and others get rest, I guess?) --- so no need to watch sitcoms, reality TV or anonymous image-boards for "a brief intermission of needed low-brow relaxation" (although nonetheless just-as-permissible). So this list is most welcome for whenever "book pace" is biologically-mentally demanded (or simply wanted) for-a-change and for a bit.
gotofritz 9y ago
> Code is punk. Go start a band. Although I understand the spirit behind this, code is most certainly NOT punk. That's what the JS / PHP / Flash script kiddies from the early 00s wrote. Or rather, it shouldn't be punk if you want to build something that is reusable, maintanable, and solid. The sad reality is that code is jazz - you can get started with Autumn Leaves or the blues, but if you want to go far you better be prepared to learn tons of theory. But I agree, you don't necessarily need to do it upfront.
- mercer 9y ago
  Why isn't code more like 'music', so punk, jazz, or some other genre entirely? Sometimes I wonder if much of the discussion/confusion that we have about 'programmers' and 'programming' arises because we treat it as a something more specific than it is. It would be like blogging, discussing, identifying with and arguing about 'writing' without distinguishing between novelists, administrative workers, legal workers, academics, poets, instruction manual writers, translators, and so on.
  - gotofritz 9y ago
    You are missing the point. OP used "code is punk" as a metaphor for "just do it without getting bogged down by theory". I have changed his metaphor to "code is jazz" to express that he's wrong, you DO need to learn a lot of the theory. I am not quite sure how what you are saying comes into this.
- rzzzt 9y ago
  "Country and Western", as said above.
slack3r 9y ago
Exactly. It seems like a terrible case of over-engineering everything and an excellent example of the planning fallacy. The book list is also too broad, IMO. It's much better to find a niche and specialize.
barrkel 9y ago
This isn't a list for learning how to code.
zeth__ 9y ago
>Code is punk. Go start a band. It's 2018. It's been 60 years since the memex and the mother of all demos. The ideas in computers aren't new or revolutionary, we know a wheel is round. The next stage is making a wheel that works better. That might work well for your crud day job, but for your own projects, why not learn from the mistakes of others and not your own? It's much simpler to read why you should do something than figuring out all the ways you shouldn't. >get to the point where you can write some idiomatic code What does this even mean? I know C back to front and there is no such thing as idiomatic C. You write one type of C for embedded, one for batch numeric, one for systems, one for real time all are "idiomatic" and all have next to nothing to do with each other. It's even worse in higher level languages.
- closed 9y ago
  > That might work well for your crud day job, but for your own projects, why not learn from the mistakes of others and not your own? There's value in learning from others, but in general, people learn more quickly from trying things right away.
  - taeric 9y ago
    In general, you have to understand the mistakes to learn from them. Often, we don't even understand what someone else was trying to do. Much less what their mistake was.
    - closed 9y ago
      That's true, and a major benefit of trying something is that it can correct for overconfidence and expose specific gaps in understanding (so you can seek out explanations, or puzzle it out)
icantdrive55 9y ago
Eddie Van Halen saw his son struggling with the Bass guitar. As a loving father, he told him, you don't need to know all the chords. He told him there's just a handful. Don't take it all on at once. Don't overthink it. (I'm paraphrasing) A lot of wisdom. I'm the biggest procrastinator. And reading about something is sometimes better than actually doing it. Crazy--I know.
begriffs 9y ago
> Now go build something. Want to do something with chat? Sure, go read up on IRC and XMPP and Signal and Wire and all that. Totally. I guess I should have mentioned that for me, at least, the books will be paired with hands-on hacking. > The idea of reading 110+ books first in the hope you'll then start your epic hack sounds to me like epic procrastination. Not planning to read book after book by the fire while the computer collects dust. :) For instance, I'm reading SQL books now and have done experiments that I then wrote about. Like transaction isolation levels, deferrable constraints, types/domains. Lots of fun stuff to build. I find that the books help to give me a broader idea of the possibilities, that's all.

rootlocus 9y ago

> Learn just enough git to create a repo, create branches, push and merge, and all that. Anything more complex? Google it when you need to like the rest of us. Bad advice. Learning git internals is surprisingly easy and has a lot of ROI. This tiny book has everything you need https://github.com/pluralsight/git-internals-pdf https://github.com/pluralsight/git-internals-pdf

yellow_postit 9y ago
What's the ROI? I tend to agree with the author on this subject here. In my case I care for just enough git to get by so I can focus on the projects I'm using git to facilitate.
- rootlocus 9y ago
  Learning "recipes" on the internet and copy pasting commands is a sure way to mess something up and could bring a lot of frustration. You only need to spend a few hours to understand how git works underneath to avoid any of that.
  - ptero 9y ago
    You should not have to learn the internals of any decent source control system to use it in a way that does not lead to a mess. An overview of usage principles and examples should be enough and should provide enough insight to search for more information if needed. User level documentation should be sufficient for user actions. If someone wants to learn internals, great; but this should be an option, not a requirement.
    - rootlocus 9y ago
      Lots of "should"s, but we're talking about advice on using git, not "any decent source control system". This is a problem I see with people not understanding git. They treat it like they think it should be treated. Like it or not, that's not going to work for git. You don't give python advice to a C++ developer, regardless of how much you'd like C++ to be like python.
      - taeric 9y ago
        This logic also works on computers. Or, well, anything. You'd be surprised at just how useful people can find things while still making a mess of them. So, yes, if you have the time, learn the internals. But no, that is not in any way a prerequisite. Nor should it be.
trentmb 9y ago
Just use fossil.

dualogy 9y ago

To quote: This list is basically a curriculum for decades of learning about the wonders of computers --- now "decades" would rather suggest that they not be perused as a full-time occupation. To your point: mostly agree, but for anyone who lives and breathes your spirit, a collection of 110+ books isn't a dangerous distraction but a welcome enriching augmentation. After some hours of coding the brain demands, deserves, benefits from --- a break. Every couple of weeks, a full day or 3. After some months, even a full week. My point? I noticed that even reading "books that deep -dive into interesting technical topics" is recreational and leisurely compared to high-intensity coding (different brain areas get stimulated and others get rest, I guess?) --- so no need to watch sitcoms, reality TV or anonymous image-boards for "a brief intermission of needed low-brow relaxation" (although nonetheless just-as-permissible). So this list is most welcome for whenever "book pace" is biologically-mentally demanded (or simply wanted) for-a-change and for a bit.

gotofritz 9y ago

> Code is punk. Go start a band. Although I understand the spirit behind this, code is most certainly NOT punk. That's what the JS / PHP / Flash script kiddies from the early 00s wrote. Or rather, it shouldn't be punk if you want to build something that is reusable, maintanable, and solid. The sad reality is that code is jazz - you can get started with Autumn Leaves or the blues, but if you want to go far you better be prepared to learn tons of theory. But I agree, you don't necessarily need to do it upfront.

mercer 9y ago
Why isn't code more like 'music', so punk, jazz, or some other genre entirely? Sometimes I wonder if much of the discussion/confusion that we have about 'programmers' and 'programming' arises because we treat it as a something more specific than it is. It would be like blogging, discussing, identifying with and arguing about 'writing' without distinguishing between novelists, administrative workers, legal workers, academics, poets, instruction manual writers, translators, and so on.
- gotofritz 9y ago
  You are missing the point. OP used "code is punk" as a metaphor for "just do it without getting bogged down by theory". I have changed his metaphor to "code is jazz" to express that he's wrong, you DO need to learn a lot of the theory. I am not quite sure how what you are saying comes into this.
rzzzt 9y ago
"Country and Western", as said above.

slack3r 9y ago

Exactly. It seems like a terrible case of over-engineering everything and an excellent example of the planning fallacy. The book list is also too broad, IMO. It's much better to find a niche and specialize.

barrkel 9y ago

This isn't a list for learning how to code.

zeth__ 9y ago

>Code is punk. Go start a band. It's 2018. It's been 60 years since the memex and the mother of all demos. The ideas in computers aren't new or revolutionary, we know a wheel is round. The next stage is making a wheel that works better. That might work well for your crud day job, but for your own projects, why not learn from the mistakes of others and not your own? It's much simpler to read why you should do something than figuring out all the ways you shouldn't. >get to the point where you can write some idiomatic code What does this even mean? I know C back to front and there is no such thing as idiomatic C. You write one type of C for embedded, one for batch numeric, one for systems, one for real time all are "idiomatic" and all have next to nothing to do with each other. It's even worse in higher level languages.

closed 9y ago
> That might work well for your crud day job, but for your own projects, why not learn from the mistakes of others and not your own? There's value in learning from others, but in general, people learn more quickly from trying things right away.
- taeric 9y ago
  In general, you have to understand the mistakes to learn from them. Often, we don't even understand what someone else was trying to do. Much less what their mistake was.
  - closed 9y ago
    That's true, and a major benefit of trying something is that it can correct for overconfidence and expose specific gaps in understanding (so you can seek out explanations, or puzzle it out)

icantdrive55 9y ago

Eddie Van Halen saw his son struggling with the Bass guitar. As a loving father, he told him, you don't need to know all the chords. He told him there's just a handful. Don't take it all on at once. Don't overthink it. (I'm paraphrasing) A lot of wisdom. I'm the biggest procrastinator. And reading about something is sometimes better than actually doing it. Crazy--I know.

begriffs 9y ago

> Now go build something. Want to do something with chat? Sure, go read up on IRC and XMPP and Signal and Wire and all that. Totally. I guess I should have mentioned that for me, at least, the books will be paired with hands-on hacking. > The idea of reading 110+ books first in the hope you'll then start your epic hack sounds to me like epic procrastination. Not planning to read book after book by the fire while the computer collects dust. :) For instance, I'm reading SQL books now and have done experiments that I then wrote about. Like transaction isolation levels, deferrable constraints, types/domains. Lots of fun stuff to build. I find that the books help to give me a broader idea of the possibilities, that's all.