> 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

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.

> You'd be surprised at just how useful people can find things while still making a mess of them.

You mean like this? http://www.thisiscolossal.com/2017/12/tatsuo-horiuchi-excel-...

I wouldn't have thought of that, but yes. :)

Most of my inspiration nowadays comes from my kids.

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.

Just use fossil.

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.

> 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.

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.

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.

"Country and Western", as said above.

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.

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

>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.

> 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.

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)