← Back to context

Comment by rootlocus

7 years ago

> The argument is focused on those who can not learn how it works.

If you're a software developer who uses branches and merges, you absolutely should learn how it works.

If you're an artist, git is not for you. It can neither store large binary files efficiently, nor merge them. There are other VCS that supposedly can, but I haven't tried them.

> Also, it's important to note that everything on that list is something that actually happened.

I can assure you, no data was permanently lost. What did happen is somebody couldn't find it, because they didn't know where to look. And I argue they should have, because git is not really that hard to learn (as a developer).

If you're an artist, git is not for you.

Exactly. That is the entire argument. From the essay:

------

I agree, Git is amazing and very powerful. What I’m suggesting is that we should recognize that it has a very high cost. It might empower complex workflows for sophisticated teams of experienced computer programmers, but it exiles the rest of the staff, and this has significant productivity costs.

...Git is very powerful? I’m willing to go along with that line of thought so long as we all understand that using a tool that is more powerful than needed can lead to problems.

http://www.smashcompany.com/business/business-productivity-h...

[ EDIT ]

Also, this bit from the essay might make the argument more clear:

For many years, I had a refrain which I gave as advice to each client I worked with: “Your software developers are expensive, so try to shift work away from them.” Ideally, software developers should only do work that relies on skills that no one else has. If a task can be done by a graphic designer, then it should be done by a graphic designer, because generally graphic designers are paid less than software developers (obviously not in all cases, but most of the time). I co-founded a startup in 2002, and I stayed with it till 2008, and we ran a team of 8 people using this principle: push work to the less skilled people, if they can handle it. Save the tough stuff for the computer programmer. We had great success with this style of work.