5 ms·

Is it normal to need that level of understanding of the inner machinery of a software to use it?

by mcc1ane 6y ago

contravariant 6y ago
Given that we're still figuring out new ways to use rocks, maybe?
oblio 6y ago
1. It is normal, as in, it's common. 2. Personally, I think this just shows how primitive our industry still is.
phailhaus 6y ago
I don't quite agree with the author that you need to understand that commits are implemented as snapshots, but yes, you need to understand quite a bit of how git works behind the scenes in order to use it effectively. This is because git tries to hide more than it should, which leads to confusion when things Go Wrong.
- deathanatos 6y ago
  I'd also say that when I've worked through people's confusion surrounding git (and other complex systems, it is because they are attempting to model the system as simpler than it actually has to be. They're not thinking of cases the system must handle, and in the absence of that (essential) complexity, they come up with an incorrect mental model that they believe works (as they're not aware of the counter-examples to it). This happens often. As another example, a former PM of mine used to assume that if our wearable recorded heart-rate data, it also had sweat data. That is, the wearable either had a lock, and recorded, or didn't. But sweat came from a different sensor than HR, and the two sensors could independently get or lose their signal. And so, sometimes one was null, sometimes the other, sometimes both, sometimes neither.
  - phailhaus 6y ago
    > They're not thinking of cases the system must handle That's not their fault; git's CLI attempts to abstract away the details and presents a falsely simple view of the world with "checkout", "add", "commit", and "push". This works for a while, until it doesn't, and then you have to face the complexity of the graph all at once. If I was going to redesign its CLI, I'd make the graph as transparent as possible.
zests 6y ago
Imagine using bash without pipes or an understanding of file descriptors.

Is it normal to need that level of understanding of the inner machinery of a software to use it?

contravariant 6y ago

Given that we're still figuring out new ways to use rocks, maybe?

oblio 6y ago

1. It is normal, as in, it's common. 2. Personally, I think this just shows how primitive our industry still is.

phailhaus 6y ago

I don't quite agree with the author that you need to understand that commits are implemented as snapshots, but yes, you need to understand quite a bit of how git works behind the scenes in order to use it effectively. This is because git tries to hide more than it should, which leads to confusion when things Go Wrong.

deathanatos 6y ago
I'd also say that when I've worked through people's confusion surrounding git (and other complex systems, it is because they are attempting to model the system as simpler than it actually has to be. They're not thinking of cases the system must handle, and in the absence of that (essential) complexity, they come up with an incorrect mental model that they believe works (as they're not aware of the counter-examples to it). This happens often. As another example, a former PM of mine used to assume that if our wearable recorded heart-rate data, it also had sweat data. That is, the wearable either had a lock, and recorded, or didn't. But sweat came from a different sensor than HR, and the two sensors could independently get or lose their signal. And so, sometimes one was null, sometimes the other, sometimes both, sometimes neither.
- phailhaus 6y ago
  > They're not thinking of cases the system must handle That's not their fault; git's CLI attempts to abstract away the details and presents a falsely simple view of the world with "checkout", "add", "commit", and "push". This works for a while, until it doesn't, and then you have to face the complexity of the graph all at once. If I was going to redesign its CLI, I'd make the graph as transparent as possible.

zests 6y ago

Imagine using bash without pipes or an understanding of file descriptors.