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.
> 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.
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.
It's very easy to end up with messy/unusable history or even lose work when you have multiple people working on related parts of a project with outdated branches and limited git knowledge.
I have been bitten by coworkers submitting preposterous pull requests because of a lack of understanding of what you can do with git and how it works that could have been avoided by taking the time to really grok git.
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.
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.
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.
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.
For years I took your position, particularly since previous VCSen such as Subversion “just worked” and generally faded into the background. However after recently taking the time to learn Git internals, and after pulling out much hair as the guy tasked with figuring out wtf Git had done with the project’s history, or why it was necessary to clone a new tree and manually copy edits over from a seemingly totally broken original tree, I now see that you just can’t use Git without a deep understanding of what it is up to and why. Not that I agree this is the right state to be in as an industry: revision control can be, and was, an almost invisible useful service, but Git just isn’t that.
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.
> 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.
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.
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.
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.
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.
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)
Depending on the hack, I’ll be using Haskell or C. Why mess with the things in between? (What’s up with everyone nowadays using a misbegotten child of the browser wars as their main language?)
What is it with so many Haskell folks being so full of themselves?
(Author here) sorry, I should work on my tone. Sometimes it feels fun to write strong statements, knowing in your own mind that you're just trying them on. Then when other people read the stuff I realize it doesn't sound daring, it just sounds arrogant. Realized this a few days ago when some podcasters covered an OpenBSD article I wrote, and when they read some of my statements out loud it sort of made me wince.
I am immediately suspect of anyone who flippantly dismisses any popular language. Languages are popular for a reason, and you can learn new things from all of them.
K&R for C was very confusing for me and I really couldn't write in C until I discovered the Harrison and Steele book. This wasn't just a personal preference either, this was the book recommended on the C lang FAQ on Usenet 25 years ago.
I'd argue that today's reference to modern/advanced SQL is Markus Winand's book which isn't mentioned either.
I learned C from the K&R book (the 2nd edition that discussed ANSI C) during my university years (circa 2000).
The book is solid for learning C and I would totally recommend it. The only gotcha is that I actually had to read it three times to properly understand all concepts (especially pointers, their relation to arrays, function pointers and their types etc). So yes it was confusing but not because the book was confusing but because the concepts are confusing (especially to a novice programmer having headaches from pointers).
Beyond K&R I would also recommend the Deep C secrets book (the one with the fish) for going "deeper".
Now i suspect that someone will come up with a totally different list - in ten years when you will be finished with this one. (i foreone still didn't get what those monads are all about :-) (nothing to be proud about...)
>you can’t beat the C language for intrinsic simplicity.
I like begriffs for his Haskell work, but I disagree with him on C. Simplicity is a good reason to prefer Wirth languages. They are similarly low-level, but beat C on safety and don't have C's abundance of undefined behavior. I suggest Free Pascal. It is similarly easy to write, compiles faster, helps you catch more bugs early and even has genetics. As I see it, there are only two major downsides to using Free Pascal: the syntax is more verbose and you have to generate and store bindings for C headers.
That's really interesting. I used Delphi back in the day to build little Windows GUI programs for personal projects, and it seemed fine. Subsequently haven't thought of Pascal much, so I guess I simply overlooked it while making The List. :)
Am I in a bubble, or is it true that C has become much more popular than Pascal? If so, why did it get popular?
Computer Organization and Design
ARM Cortex A72 Software Optimization Guide
Intel® 64 and IA-32 Architectures Optimization Reference Manual
The microarchitecture of Intel, AMD and VIA CPUs
Parsing
Language Implementation Patterns
The Definitive ANTLR 4 Reference
Handily enough, the links go to goodreads where you can read reviews and determine that for yourself.
Consider the list as a discovery mechanism and then use your own judgement to determine whether it's worthwhile or not. The value is in the discovery, rather than a (non-existent) review.
I mean the article seems very random, linking to some bad books and some good ones. I'm assuming the ones with 3+ stars on Goodreads are poor because the author doesn't say anything to justify why they're decent. There's no hint that the author even reads these books.
I already have a bottomless list of books to read, so some form of filter would be nice. There are better methods of discovery, like finding respectable programmers in a field and then reading what they like.
Unless I'm missing something, the article doesn't make any effort to establish credibility, so it's similar to any other teenager recommending a stack of books.
It's a list of books per topic that the author thinks are valuable books for some topic. With the link through to Goodreads, it actually probably doesn't really matter _why_ the author liked it - I don't know the author, so the authors reasoning would be the opinion of a random person, and Goodreads collects the opinion of a whole bunch of random people.
So why this article? Yeah, it is pretty much a discovery mechanism. To me, the author is saying "I liked these books," or "I think these books are good," and "Here's what other people said about these books." I knew of some of the books and I didn't know of others, so mission accomplished, to be honest.
A good list, but not for me. My interests are in general AI, specifically machine learning, and recently in a few open source blockchain platforms. The world would be a boring place if we were all into the same things.
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/2...
Code is punk. Go start a band.