The worst part about Git is the "Git-SVN Crash Course" tutorial, because it will convince a newcomer that their understanding of how source control works transfers smoothly to Git. If you combine that with the fact that most smart people simply refuse to read documentation and will just mash on the keyboard until it appears to work, it means that teams who are starting out using Git are on the yellow brick road to a world of hurt.

Git follows Linux's philosophy of refusing to protect you from yourself. Much like Linux, Git will sit back and watch you fuck your shit right up, and then laugh at you as you try to get your world back to a state where up is up and down is down. As far as source control goes, not a lot of people are used to this kind of free love.

Milo has been using Git from the get-go, and the git pull/git push with a central repository works well enough when you only have a handful of developers.

This fits with the Subversion worldview that a benevolent central server will never lead you astray. The first time you get some error about not being able to push non-fast-forward commits to origin, you kind of gloss over it, and a git pull fixes you right up. If you understand Git as you understand SVN, you can easily mistake this error for something like "oh, I just have to do a merge because someone else's commits beat me to it". Well, technically that's right, but for the wrong reasons. Using this model, if you think of the developers as different threads sharing the origin repository resource, Git is putting lock on the whole repository, as opposed to individual files. With a lot of threads sharing a coarsely-locked resource, there's always going to be contention. However, in a small enough team, it's workable to think of it this way.

This is where smart people run into trouble. We know in the backs of our minds that something is just a little off about that non-fast-forward-commit error message, but everything looks fine, so why go read about what's going on? I am generally not a fan of reading documentation until I am debugging a problem, because I expect software to behave as it would if I wrote it. Good documentation is condescendingly terse, and Git's documentation is like an art critic who giggles at you. (The description of git-rebase is "Forward-port local commits to the updated upstream head". Oh, fuck off.)

In the last couple of weeks, we started using Gerrit for code reviews, and anyone who was using Git like a translation table for SVN commands just heard the bell ring at the School of Hard Knocks.

Gerrit acts as an intermediary between developers and the origin repository. You send commits to Gerrit and it holds them in purgatory until they are signed off on by another developer. Then, if the commit applies cleanly to the branch, Gerrit applies it. Otherwise, it asks you to upload a merge commit, which is where the fun really starts.

The upside to this system is that it prevents other peoples' git-fuckups from becoming your git-fuckups. The downside is that because commits are held in this transient state, it's very easy to lay a path of destruction through your local repository with rebase and merge if you don't completely grok what's going on. Like old skid marks on a highway, our codebase is peppered with merge commits and cherry-picks that are the only living records of a series of oh-shit moments.

The problem isn't that Git is to hard, it's that smart developers are impatient and have exactly zero tolerance for unexpected behavior in their tools. While Git is the trendy thing right now, perhaps some day you will come across a grizzled developer who is using SVN, and when you ask him why, his answer won't make sense, because it's a Zen thing.

Most college mathematics or computer science departments have a "crank bin": a box with collected papers that people have sent in for review. There are all sorts of gems in there: a two-page proof of the Riemann hypothesis, a drawing that demonstrates P = NP, and of course, a draft of a patent application for a free energy machine. Many professors just throw this crap out, but some collect it because it makes for a good read when you're feeling discouraged by a hard problem.

Me, whenever I need a pick me up, I go read some of the latest new techniques for SEO. There are a handful of fundamentals about page design and other nitty things like URL structure that are generally accepted as good SEO, and you can derive all of this from the principles of not completely failing at web design. Non-brain-damaged web design and link building are 100% of SEO.

Anyone who tells you different is a quack that is only trying to separate you from your money.

Quackery in medicine is pretty easy to spot, and quackery in computing is pretty similar:

• "Research" performed by people with slim technical backgrounds
• Suspect experimental controls or no experimental controls
• Little investigation of alternative explanations for phenomena
• Little to no data reported from findings

Let's look at my favorite example: SEOMoz. It's a wealth of collected information about SEO, almost completely anecdotal, and of course you can get access to more "professional" information for a fee. There probably a place on the site where you can buy Acai berries, but I haven't found it yet.

SEOMoz recently published a correlation analysis of ranking factors for Google and Bing. First of all, out of all the factors they measured ranking correlation for, nothing was correlated above .35. In most science, correlations this low are not even worth publishing. As a warm-up, the author explains a graph that shows negative correlation with rank for URL length and .com TLD extension, meaning that longer URLs were less high up in the search results as were URLs that came from .com domains:

This is the explanation, verbatim:

The data for URL length shows that longer URLs are negatively correlated with ranking well. This isn't particularly shocking, and it probably iswise to limit the length of our URLs if we want to perform well in the engines. However, the second data point on .com TLD extensions shouldn't necessarily suggest that using .com as your top-level domain extension will actually negatively affect your rankings, but merely that all other things being equal, .com domains didn't perform as well in the dataset we observed as other domain extensions.

That is not how science works. You can't discount data just because you feel like it. Also notice that the most negative correlation metric they found was -.18. A correlation of zero suggests that the two variables are completely independent of one another. Such a small correlation on such a small data set, again, is not even worth publishing.

There is no hypothesis being tested here. It's just graphs, and misleading graphs at that. The sad part is, SEOMoz is as close as the SEO industry comes to real science. They may be presenting specious results in hopes of looking like they know what they're talking about, but at least they are collecting some sort of data.

Everything else in the field is either anecdotal hocus-pocus or a decree from Matt Cutts. When you hire an SEO consultant, what you are really paying for is domain experience in the not-failing-at-web-design field. It's fine to pay for this kind of service, but beware of anyone who claims to have studied the effects of different techniques. They might give you skin failure.

Update: It looks like I am not the first one to notice this. Here is a good article with more statistical formalism on SEOMoz quackery.

Here’s to the crazy ones. The misfits. The rebels. The troublemakers. The round pegs in the square holes. The ones who see things differently. They’re not fond of rules. And they have no respect for the status quo. You can praise them, disagree with them, quote them, disbelieve them, glorify or vilify them. About the only thing you can’t do is ignore them. Because they change things. They invent. They imagine. They heal. They explore. They create. They inspire. They push the human race forward. -- Apple ad, 1997.

My first computer was a 33MHz Macintosh Performa 637-CD. It had 8 megabytes of memory. It was one of the newer Macs that featured a CD-ROM drive. We bought Apple's 2400 baud modem as an accessory, and signed up for eWorld.

The one thing that got me into exploring computers in the first place was learning how to hack the game Escape Velocity using ResEdit, Apple's pistol-without-a-safety tool that was supposed to be for developers but available to anyone. (I became an expert at fresh-installing MacOS 7.5)

At the time, I was about as fanboy as they came. This was around the era when Apple was long considered the walking dead, only kept standing by the mercy of Adobe continuing to release Photoshop, and Microsoft, possibly to keep the antitrust litigators out of their ass, publishing Office for the Mac. Being a Mac user in the late nineties, you had this feeling that you were on the side of right — that the competition wasn't about megahertz or gigabytes, but that the counterculture was the spark that would give way to the natural order of things. We thought we were on the ground floor of the inevitable.

Apple now stands as a monument to the failure of that free-thinking counterculture. We thought that freedom from the tie-wearing, meeting-holding, memo-dictating corporate world was going to be the catalyst for utopian computing, and that Steve Jobs had the vision for how it was all going to work. Maybe he did, maybe he didn't, but that utopian endgame is quickly de-evolving into a dictatorship.

It started with Apple's tight control on the iPhone app market, the approvals process, and the well-manicured app store. Now, Apple is not only dictating what applications may or may not run on the iPhone or iPad, but they are also dictating the language in which apps must be written. Their justification for all of this is "for the good of the user", but it might just be the capstone delusion of an aging hippie who never got a chance to run for Congress. I predict that within five years, Apple will begin telling development shops what kinds of apps they should make. Why? Because it will be "good for the user", and you know, Mr. iPad developer, apps that are good for users usually sail right through the approvals process. Apple's iPhone/iPad department will be renamed Central Planning, and may God help you if you cross them.

I could be wrong, though. The backlash had been pretty severe, to the point where it may be getting to Steve Jobs. Take, for example, a recent e-mail exchange he had with a Gawker reporter, in which Jobs took a shot:

By the way, what have you done that’s so great? Do you create anything, or just criticize others work and belittle their motivations?

Back when I was writing Uncov, I would see this particular flavor of ballache pretty frequently, and it was a very good indicator of the person's nerves. The thing is, being a CEO, you need to be able to let the critics roll off your back. We talk shit, it's our job, and the bigger the shit we talk, the more we get paid. Most executives know this, and don't respond to us trolls. It's only when they're starting to wear down do they bust out the Teddy Roosevelt man-in-the-arena speech. (By the way, Theodore Roosevelt was shot in the chest once, and proceeded to deliver a speech with the bullet still in him. He left the bullet in his body until his death seven years later. Executives: That shit's hard core...you are not TR.)

I will still probably buy an iPhone some day because they are very cool. However, I will never develop for it, because I'm a crazy one. A misfit. And I'm not fond of rules.

Now where did I pick up that idea?