Safe from the Losing Fight

Lately it seems there’s been a lot of talk about distributed version control systems — especially git and Mercurial — and how they’re the bee’s knees or possibly even the cat’s pajamas.

But at the risk of having my programmer’s license revoked, I have to confess I don’t really care about version control systems. I mean, I think it’s important to use version control, but I don’t get all excited about the latest ideas in version control technology or the newest VCS on the block. It’s just a tool. It keeps versions of all my code, and allows me to revert to previous versions, see when and how things changed, and collaborate with other programmers working in the same codebase. Beyond that I don’t much care.

The tools don’t make the programmer.

What’s new with DVCS is the proponents seem to think they need to evangelize their system. Unfortunately they rather suck at it, and their arguments usually leave me feeling that I don’t want to use software used by such jerks, on account that it might make me into a jerk. Or at least a bigger one.

However, I do think that a DVCS can be a really useful tool so I’ve come up with some suggestions for those wanting to effectively evangelize their favorite version control system, or at least annoy me less when they talk.

1. Don’t be condescending or insulting

   I think it’s part of human nature — or at least programmer nature — to assume you’re the smartest guy in the room, and think that anyone who disagrees with you is a real buffon. Programmers seem to take great pleasure in showing that the other person is an idiot, or didn’t know something they did, or is at least not as clever as they are. A lot of arguments for git or Mercurial seem to revolve around explaining how git or Mercurial are so clearly superior that only morons would use something else.

   While this works great for rallying the troops, it’s counterproductive when trying to win someone over to your side.

   Think of it this way: suppose someone comes to your door to tell you about their religion. During the discussion they are self righteous and condescending; they don’t listen to your arguments, but are only interested in proving that they’re right. Are you likely to be swayed to believe in their religion? If you’re like the other hairless bipedal mammals inhabiting this planet you won’t be, even if they had some valid points.

   As soon as you become insulting or condescending, your arguments will be rejected out of hand. I know this will upset some programmers because they believe if you show your argument is superior, everyone will accept it. But that’s not the way people work.

2. Try to be helpful

   The best way to introduce someone to your DVCS is by trying to help them. Not in the “I have all the answers” way, but in the “I’ve dealt with that before, and here’s what I did” kind of way. People will run into the kinds of problems that DVCS are good at solving. When they do, you can helpfully suggest a solution.

   However, some care should be taken so the suggestion doesn’t come off the wrong way.

   Wrong	Right
   Dude, why are you using subversion?	I’ve run into that problem before. I solved it by using feature X of git/hg in this way.
   Dude, just use git/hg.	You smell nice.

   Be aware that people may not know where their pain points are. I’ve seen customers jump through some excruciating hoops to get a piece of software to do something when there was an easier way. People get used to pain and begin to assume it’s normal. If you notice something like that, even if they’re not complaining about it, you can politely suggest a better way.

   Instead of a list of features that a DVCS provides or abstract arguments as to why they should be using it, people respond better to concrete examples of how a piece of software can make their lives better. People are also more responsive when they know you’re on their side, trying to help them, even if they don’t — or currently can’t — take your suggestion. Keep in mind switching VCS in the middle of product cycle is likely something most people can’t do.

   The right attitude is that of trying to help a friend, not conquer an enemy.

3. Be willing to answer questions, even dumb ones

   Distributed version control works differently from centralized version control, and it does require a different way of thinking. I know I was confused by it when I first started looking into it. A lot of tutorials jump into the mechanics of how to perform certain tasks, but rarely talk about the philosophy of the system or why things are the way they are. If you want to successfully persuade people that your DVCS is the best then you need to be willing to do a lot of patient education.

   I say “patient” because after using centralized version control they might have difficulty switching over to a new mental model. Or they might have heard a lot of FUD about your DVCS that you need to put to rest. It’s important to do this patiently, respectfully, and not insultingly because they’ve picked up misinformation or don’t immediately “get it” like you do. Otherwise they might ignore your DVCS so they don’t have to deal with people who look down on them because they don’t “get it.”

4. Make it trivial to install and use

   This seems like a no brainer, but it is an important part of any software. If it’s hard to try out and use your DVCS, it simply won’t get used. I think that for the most part both git and Mercurial succeed in this respect. My only complaint is neither has a good Mac GUI client. Contrast that with Subversion which has both Versions and Cornerstone on the Mac. You shouldn’t underestimate the draw of an easy to use, beautiful GUI.

I think Joel Spolsky has given the best example of how to properly promote and evangelize a DVCS. He wrote a blog post — Distributed Version Control is here to stay, baby — about how he came to learn and use DVCS. It’s well written, and instead of condescending, he’s actually humble and admits he was wrong about DVCS to begin with. Joel also created a site called HgInit that does an amazing job of explaining the philosophy behind Mercurial and gives a solid introduction to right way to use it. It’s actually the site that convinced me to start using Mercurial for real.

I just realized I hadn’t posted to my blog in a few months. The lack of content has been caused both me just being busy, and me being on Twitter.

If you would like to follow me, I’m macgeek02. I’ll update my contact page to contain my handle as well.

I still definitely have plans for more graphics articles, it will just take me a while to write and post them.

You might have noticed, especially given the last post, that the code formatting on this blog leaves much to be desired. I’m trying to rectify that, but I’m not quite sure how to do it.

I’ve always assumed that when presenting code, I should use the the <code> tag. Unfortunately, the default formatting of this tag is indeterminate at best. From trial and error I’ve determined that it’s usually best to put each line of code in its own set of <code></code> tags, otherwise formatting gets really wonked. I’ve also found, depending on the CSS, I might have to put a <br> after each line of code, otherwise my nice, pretty function all ends up on one line.

And this completely ignores indented code. There seem to be a couple of ways to making indentation work. The first is to use the white-space: pre; CSS rule and make sure the tab characters are in the <code> tags. The second is to use the text-indent CSS attribute for each line of code I want to indent.

None of these options are easy or simple, which makes me think I’m doing something wrong. Are there are any web designers/HTML coders in the audience that know the proper way of doing this? Surely it’s not intended to be this painful.

The problem with formatting code on this blog has led me to the conclusion that I’m probably going to have to ditch my current WordPress theme. Sure it’s pretty, but it does float: right on my images with a rule that has high specificity, making it very difficult to not float my images to the right, which is what I usually want. It also has a fixed width, which doesn’t really mix well with my code examples, not to mention it doesn’t style the <code> tags well.

Unfortunately I haven’t been able to to find an appropriate WordPress theme that will fit my needs. I’d really like a two column layout, with a fluid width, and, if it’s not too much to ask, decent <code> tag handling.

I just noticed that I haven’t posted in a very long time. I blame the move.

I had to visit the Bay Area twice before I found any place that was worth having. Not a great place, but I was really pressed for time and it had the least number of things wrong with it. I get to pay over twice what the same apartment would cost in Dallas for the privilege of being in great state of California. For a place that’s famous for people claiming you can’t own property, property sure does cost a lot there.

Anyway, with all the running around and whatnot, there hasn’t been that much time to blog. Now that I’m back in Dallas I have to finalize all the move details within the next two weeks, after which the movers arrive and move all my junk to an undisclosed, but highly expensive, location. It is doing wonders for my stress level. It’s a good thing I only move across the country every two years.

This is coupled with a new contract that finally started after literally two months of negotiation. The problem was the client’s lawyers got involved. In small companies, the client’s lawyers are on the same side as their client, because they’re not in-house and can be let go easily. In large companies, the lawyers are on neither our side nor the side of the client. Their side is the side in which nothing happens, therefore they cannot be blamed for it. Anyway, the contract is a week old and already a month behind. It’s gonna be fun, I can tell.

All this is to say I’m not going to posting for a while. At least until all this stupid move stuff calms down, which will probably won’t be until mid-April or so.

P.S. Is there anyone in the Dallas area who would like to buy a full size washer and dryer? I’ll sell them on cheap. It is apparently illegal in California to own such things. Some people smuggle in those stackable mini washer-dryer units that have the capacity of a small salad bowl, which is what the owner of the “condo” I’m renting has done.

This past Sunday night I decided that I should check to see how traffic to the ‘ol site was doing. I had been neglecting monitoring the site for a while because, well, I was busy on Wombat, and because traffic was predictable. I knew pretty much who had already linked to me, and how much traffic that typically brought in.

Sunday nights are usually slow. But not this one. There was definitely a growth in traffic, and it appeared to be coming from Cocoa Dev Central. hmmm… that’s odd. Why would anyone over there link to me? Using my powerful investigative and deductive skills, I uncovered this (it was on the front page):

Oh my.

I have to admit my first reaction was: Why did they link to me? I mean, they should be linking to Wil Shipley or Daniel Jalkut, who actually write about Cocoa regularly, and have a great deal more experience with it than me. Don’t get me wrong, I was happy to see the link, but I was worried that people would assume I was some sort of Cocoa master, or that I only wrote about Cocoa.

After a while I began to relax and realize that all the other blogs cover somewhat diverse topics as well, and that I had been covering Cocoa recently, in the form of Core Data. So I calmed down. Calm. Calm is good.

Then came today. I’m not sure if it was because Scott Stevenson announced the redesign of Cocoa Dev Central on his site or what, but I got an even bigger spike in traffic. Scott’s post also confirmed my suspicion that he was the one running Cocoa Dev Central. So, thank you Scott. I really appreciate the link.

…

I’m still in shock that I’m on the same list that includes Wil Shipley and John “Wolf” Rentzsch. Hopefully they’re not too offended about the whole thing.

I should also point out the other new addition to the Cocoa Dev Central blog roll: Cocoa Samurai by Colin Wheeler. He appears to be just as surprised as I am, albeit a bit more on topic with the whole Cocoa thing.