5 ms·

I guess. To me, the opposite is a more worthy essay: why, with all the power to customize our tech, do we create things that consistently work differently than

I guess. To me, the opposite is a more worthy essay: why, with all the power to customize our tech, do we create things that consistently work differently than people's intuition? The fact that it "mostly jibes" feels like a footgun, not a feature. I get that for some, "git just works! It made sense from day one" but in my limited experience, 0% of people I've worked with have said that. Sure, we can all learn the tech. And expert techniques in any field often don't jibe with naive expectations. But for me and the folks I work with, the tech industry feels like it's gliding more towards inscrutible tools vs ease of use. We've hit a stage where many rely on code completion bots and answer-supplying bots instead of being able to directly embrace our tech. I wish the tech was more approachable on its own, but perhaps this is the natural evolution of things.

xanderlewis 3y ago
That doesn’t seem like the opposite to me. It seems like the same thing. Rather than rejecting people’s intuition as ‘understandable but wrong’ why don’t we use it as the basis for a better solution?
atq2119 3y ago
You do have a point, but it's not a slam dunk. Intuition isn't some fixed thing but arises from personal experience. A lot of that is common to a culture, but there are different cultures and in any case, some truly personal aspects remain. There needs to be a balance between creating new, more powerful intuitions, and meeting people at the intuitions they already have. Case in point, Git's branching model is pretty intuitive when you understand how Linux kernel development works. Perhaps 0% of the people you've worked with have looked into that. That's fine. Different cultures... Another example that may be worth studying is mathematics and the hard sciences. Learning those is a lot about learning powerful intuitions.
- BlueTemplar 3y ago
  Yeah, few things are actually "intuitive". "Shared familiarity" is probably a better term.
eviks 3y ago
Partially because that's a much harder design challenge, especially for people with an unrelated skill set
chthonicdaemon 3y ago
People writing software fall into several categories based on the problem they're solving, the reason they're solving it and the audience of the solution. I solve my own problems for my own reasons all the time and therefore other people's intuitions are immaterial in the process. It would just slow me down to think "how would other people use this" when I'm focused on some technical personal problem. Commercial software developers solve problems with the clear purpose of selling the solution to others and where they know ahead of time roughly what their audience's intuitions are. This is why intuitive GUI applications exist - there are whole industries devoted to finding out what people expect, what lowers cognitive load etc. iOS and Android apps give you a good idea of what is possible with modern tech when the purposes are properly aligned. The problem here is that git was expressly developed by Linus to solve his own problem in a way that made sense to him with no thought as to how other people would use it. There were no focus groups, early betas, feedback from users and so on. At best there has been slow fixes to the porcelain to fix the stuff that bothers the people who could make a PR to git. On the other hand there are also many front-end projects that attempt to align some other person's idea of how version control is supposed to work with the Git model. Anyway - I am in the camp where I very seldom get confused about a git thing because the actual expressed model is really simple (in the way that x86 assembly is a "simpler" language than Java). I find most front-ends much more confusing because they don't seem to work the way I expect. But I am never surprised when someone's pet project is understandable only by themselves. Or indeed when a consumer product is consumer-friendly. The real surprise is when a lone programmer makes something for themselves that then goes on to have wide appeal.
ndriscoll 3y ago
As one of those people that thinks it's extremely intuitive, I have to wonder where the confused people are learning about git. The documentation on the site[0] is quite clear: > A branch in Git is simply a lightweight movable pointer to one of these commits. The default branch name in Git is master. As you start making commits, you’re given a master branch that points to the last commit you made. Every time you commit, the master branch pointer moves forward automatically. It has multiple diagrams explaining how commits point to their content and their parents, and branches point to commits. The Pro Git content has been there for at least 10 years (it's what I learned from 10 years ago). Maybe the problem is just that the Internet is full of blogs that have incorrect diagrams (like those in the OP) and bad explanations, despite the main website having great documentation! [0] https://git-scm.com/book/en/v2/Git-Branching-Branches-in-a-Nutshell https://git-scm.com/book/en/v2/Git-Branching-Branches-in-a-N...
- chihuahua 3y ago
  If Git was "extremely intuitive", and the documentation was "great", why would so many otherwise smart people keep writing blogs about it with incorrect diagrams? What is your theory about why so many people are having difficulty creating a correct mental model about Git, and why so many people are writing incorrect blogs about it?
  - ndriscoll 3y ago
    Like I sort of implied, my theory is people haven't read the docs on the official site (or the book that's on the site), and keep regurgitating bad information that they read on some blog or howto site. I don't know why they do this. I don't make these sites, so I don't know what motivates people who do, especially people who don't understand what they're writing about. If you understand the basic design premise (commits are content-addressed immutable snapshots), the pointer stuff is kind of obvious. It has to work something like that for it to be able to be immutable if you want to be able to make branches/tags after the commit is created.
  - afiori 3y ago
    In part it is because git is hard to use, in part it is because mostly people learn git by oral tradition and often treat it like sorcery.
marcosdumay 3y ago
Often, people's intuition is wrong on very important ways, and something that works like they expect is sure to create footguns or just blow up by itself. But I'm not sure git is a case of this. The DVCS that were created following people's intuitions were known to be slow and internally complex, but I have never heard about them failing. (And the slowness is obviously of a kind that can be optimized away.) We just stuck with the worst UI ever devised in public for a VCS because of network effects.
- chihuahua 3y ago
  I totally agree with it being "the worst UI ever devised". It's fine to use commits with parent pointers and branches as pointers to commits and all the other stuff internally. But there should be a UI wrapped around that that maps to operations that make sense for the purpose of working on a software project. Not this: git merge [-n] [--stat] [--no-commit] [--squash] [--[no-]edit] [--no-verify] [-s <strategy>] [-X <strategy-option>] [-S[<keyid>]] [--[no-]allow-unrelated-histories] [--[no-]rerere-autoupdate] [-m <msg>] [-F <file>] [--into-name <branch>] [<commit>… ]
codesnik 3y ago
because a) everyone's intuition is different, b) sometimes uneducated intuition is just wrong. On a surface level things looks good, but in some specific situation intuitive ways of doing things could be not consistent or don't have any solution at all. In this cases you just stuck with magic box of software which did something and you have no idea what and reach for backup. Git is not like that. It is very-very simple. If you learn basics of it, your intuition will align with git's "intuition" too, and you can do crazy things with total peace of mind, without googling or looking into source code of git to see how they had to make something "intuitive" in some definition of the word.
timacles 3y ago
This is the same reasoning that SQL gets criticized with. But the answer is simple. Git (and sql) range from simple task to very complicated. Everyone likes to fantasize about making it easier but they’re only thinking about the fraction of functionality they use, rather than everything it currently does. If someone could come up with a simpler solution they would, but they can’t because git can do extremely complicated things and is internally consistent. Most people underestimate that part
hinkley 3y ago
> do we create things that consistently work differently tquadraticallyhan people's intuition? I don't know if this is true of git, but in general we have a disease called, "solving problems we don't have". I don't mean the YAGNI issue, or people trying to talk others out of doing engineering because the current masochistic process is good enough. I mean the impedance mismatched caused by taking a concrete, physical problem, translating it into a domain that looks nothing like the problem you're meant to solve, and then tweaking how the fiction works so that it fulfills the requirements. A few wise people have warned me off of this strategy over the years, but there's not nearly enough ink spent on this topic. This impedance mismatch gets worse over time. They asked for X, and you gave them Y, so when they ask to refine X into X + 1, it gets a little harder each time. The complexity goes up and you find confused product owners asking for what should be a simple change and getting tremendous pushback that smells a lot of deflection. Meanwhile because users think the system works one way, they expect it to behave in certain ways and constantly get rudely surprised by how it actually works. Again and again in my career, I've found that a lot of performance problems are obscured by accidental complexity and/or X-Y problems, and once you know the task you actually need to perform, and write the code to solve the actual problem instead of an analog, everything becomes clearer. A mix of determinism and pre-determinism (static calculation) makes for a much faster system without sacrificing legibility in the process. The issue, I think, is that people find the problems they are given to be boring, and so they try to solve an analogous problem they find more entertaining - at first. There are other ways to find joy and fulfillment in simple tasks besides making them into stunts.

xanderlewis 3y ago

That doesn’t seem like the opposite to me. It seems like the same thing. Rather than rejecting people’s intuition as ‘understandable but wrong’ why don’t we use it as the basis for a better solution?

atq2119 3y ago

You do have a point, but it's not a slam dunk. Intuition isn't some fixed thing but arises from personal experience. A lot of that is common to a culture, but there are different cultures and in any case, some truly personal aspects remain. There needs to be a balance between creating new, more powerful intuitions, and meeting people at the intuitions they already have. Case in point, Git's branching model is pretty intuitive when you understand how Linux kernel development works. Perhaps 0% of the people you've worked with have looked into that. That's fine. Different cultures... Another example that may be worth studying is mathematics and the hard sciences. Learning those is a lot about learning powerful intuitions.

BlueTemplar 3y ago
Yeah, few things are actually "intuitive". "Shared familiarity" is probably a better term.

eviks 3y ago

Partially because that's a much harder design challenge, especially for people with an unrelated skill set

chthonicdaemon 3y ago

People writing software fall into several categories based on the problem they're solving, the reason they're solving it and the audience of the solution. I solve my own problems for my own reasons all the time and therefore other people's intuitions are immaterial in the process. It would just slow me down to think "how would other people use this" when I'm focused on some technical personal problem. Commercial software developers solve problems with the clear purpose of selling the solution to others and where they know ahead of time roughly what their audience's intuitions are. This is why intuitive GUI applications exist - there are whole industries devoted to finding out what people expect, what lowers cognitive load etc. iOS and Android apps give you a good idea of what is possible with modern tech when the purposes are properly aligned. The problem here is that git was expressly developed by Linus to solve his own problem in a way that made sense to him with no thought as to how other people would use it. There were no focus groups, early betas, feedback from users and so on. At best there has been slow fixes to the porcelain to fix the stuff that bothers the people who could make a PR to git. On the other hand there are also many front-end projects that attempt to align some other person's idea of how version control is supposed to work with the Git model. Anyway - I am in the camp where I very seldom get confused about a git thing because the actual expressed model is really simple (in the way that x86 assembly is a "simpler" language than Java). I find most front-ends much more confusing because they don't seem to work the way I expect. But I am never surprised when someone's pet project is understandable only by themselves. Or indeed when a consumer product is consumer-friendly. The real surprise is when a lone programmer makes something for themselves that then goes on to have wide appeal.

ndriscoll 3y ago

As one of those people that thinks it's extremely intuitive, I have to wonder where the confused people are learning about git. The documentation on the site[0] is quite clear: > A branch in Git is simply a lightweight movable pointer to one of these commits. The default branch name in Git is master. As you start making commits, you’re given a master branch that points to the last commit you made. Every time you commit, the master branch pointer moves forward automatically. It has multiple diagrams explaining how commits point to their content and their parents, and branches point to commits. The Pro Git content has been there for at least 10 years (it's what I learned from 10 years ago). Maybe the problem is just that the Internet is full of blogs that have incorrect diagrams (like those in the OP) and bad explanations, despite the main website having great documentation! [0] https://git-scm.com/book/en/v2/Git-Branching-Branches-in-a-Nutshell https://git-scm.com/book/en/v2/Git-Branching-Branches-in-a-N...

chihuahua 3y ago
If Git was "extremely intuitive", and the documentation was "great", why would so many otherwise smart people keep writing blogs about it with incorrect diagrams? What is your theory about why so many people are having difficulty creating a correct mental model about Git, and why so many people are writing incorrect blogs about it?
- ndriscoll 3y ago
  Like I sort of implied, my theory is people haven't read the docs on the official site (or the book that's on the site), and keep regurgitating bad information that they read on some blog or howto site. I don't know why they do this. I don't make these sites, so I don't know what motivates people who do, especially people who don't understand what they're writing about. If you understand the basic design premise (commits are content-addressed immutable snapshots), the pointer stuff is kind of obvious. It has to work something like that for it to be able to be immutable if you want to be able to make branches/tags after the commit is created.
- afiori 3y ago
  In part it is because git is hard to use, in part it is because mostly people learn git by oral tradition and often treat it like sorcery.

marcosdumay 3y ago

Often, people's intuition is wrong on very important ways, and something that works like they expect is sure to create footguns or just blow up by itself. But I'm not sure git is a case of this. The DVCS that were created following people's intuitions were known to be slow and internally complex, but I have never heard about them failing. (And the slowness is obviously of a kind that can be optimized away.) We just stuck with the worst UI ever devised in public for a VCS because of network effects.

chihuahua 3y ago
I totally agree with it being "the worst UI ever devised". It's fine to use commits with parent pointers and branches as pointers to commits and all the other stuff internally. But there should be a UI wrapped around that that maps to operations that make sense for the purpose of working on a software project. Not this: git merge [-n] [--stat] [--no-commit] [--squash] [--[no-]edit] [--no-verify] [-s <strategy>] [-X <strategy-option>] [-S[<keyid>]] [--[no-]allow-unrelated-histories] [--[no-]rerere-autoupdate] [-m <msg>] [-F <file>] [--into-name <branch>] [<commit>… ]

codesnik 3y ago

because a) everyone's intuition is different, b) sometimes uneducated intuition is just wrong. On a surface level things looks good, but in some specific situation intuitive ways of doing things could be not consistent or don't have any solution at all. In this cases you just stuck with magic box of software which did something and you have no idea what and reach for backup. Git is not like that. It is very-very simple. If you learn basics of it, your intuition will align with git's "intuition" too, and you can do crazy things with total peace of mind, without googling or looking into source code of git to see how they had to make something "intuitive" in some definition of the word.

timacles 3y ago

This is the same reasoning that SQL gets criticized with. But the answer is simple. Git (and sql) range from simple task to very complicated. Everyone likes to fantasize about making it easier but they’re only thinking about the fraction of functionality they use, rather than everything it currently does. If someone could come up with a simpler solution they would, but they can’t because git can do extremely complicated things and is internally consistent. Most people underestimate that part

hinkley 3y ago

> do we create things that consistently work differently tquadraticallyhan people's intuition? I don't know if this is true of git, but in general we have a disease called, "solving problems we don't have". I don't mean the YAGNI issue, or people trying to talk others out of doing engineering because the current masochistic process is good enough. I mean the impedance mismatched caused by taking a concrete, physical problem, translating it into a domain that looks nothing like the problem you're meant to solve, and then tweaking how the fiction works so that it fulfills the requirements. A few wise people have warned me off of this strategy over the years, but there's not nearly enough ink spent on this topic. This impedance mismatch gets worse over time. They asked for X, and you gave them Y, so when they ask to refine X into X + 1, it gets a little harder each time. The complexity goes up and you find confused product owners asking for what should be a simple change and getting tremendous pushback that smells a lot of deflection. Meanwhile because users think the system works one way, they expect it to behave in certain ways and constantly get rudely surprised by how it actually works. Again and again in my career, I've found that a lot of performance problems are obscured by accidental complexity and/or X-Y problems, and once you know the task you actually need to perform, and write the code to solve the actual problem instead of an analog, everything becomes clearer. A mix of determinism and pre-determinism (static calculation) makes for a much faster system without sacrificing legibility in the process. The issue, I think, is that people find the problems they are given to be boring, and so they try to solve an analogous problem they find more entertaining - at first. There are other ways to find joy and fulfillment in simple tasks besides making them into stunts.