Because of the kind of work I do, wholesale consulting, I'm pretty much never in on the beginning of a project. It's been a near universal truth that by the time I come on to a project, not only has the entire project been set up, it's frequently in trouble. That's when projects often turn to outside help.
And, I have yet to be on a project where you can actually jump in and start working without first wrestling with repository URL's, environment variables, IDE settings, missing build tools and about 10,000 assumptions. Particularly noteworthy is the fact that nearly every one of these conversations started out with the exact same statement he quotes:
"Just check it out and you'll be right to go."
That sentence hides this giant pile of assumptions and contains one of my least favorite words: "just". Nearly every time you hear it or it's friends: only and "all", as in "all you need to do", someone is leaving out a huge part of what's really involved. Sometimes they don't know what they're leaving out, but other times, people are doing it on purpose.
Regardless, it's filled with all of the crap that you'll only find out the hard way. Or, if you're in the kind of environment I've been working with lately, the entire staff that came up with the build procedure for every one of dozens of software projects is long gone. The only thing that's more frustrating than having that long conversation with the existing lead developer is having it with one who isn't there.
Like he says in the article, it only takes a couple of days and less than 10 pages to write this stuff up. Then, instead of every developer who comes on wasting 1-2 weeks before writing a single line of useful code, they can spend a couple of hours getting started and start contributing right away.
Or, you can keep having those conversations. I know I have been for the last month or so.