5 ms·

"Rocket science is easy once you understand the underlying principles of rocket science"

unicornmama 4y ago
It amazes me the amount of engineers who can use a tool every day yet remain not the least bit curious to its basic internal operation.
- ironmagma 4y ago
  Perhaps it is that they actually are curious, but the amount of knowledge to be had is quite substantial.
  - seba_dos1 4y ago
    I don't think that's the case with git though? It's fairly simple actually. The biggest (only?) challenge is to not view it as a tool to do versioning of your code, but rather a tool to work on data structures that effectively do versioning of your code. It seemed fairly straight-forward to me once I did that mental shift.
    - ironmagma 4y ago
      Everyone says that, but I don’t find it to be true. For context, we run a Gitea fork at work, and I often have to read the source code inherited from upstream Gitea. There are a ton of things that can happen during a merge, for example. Does anyone know what a smudge filter actually is? Why are there branches, and also tracking branches? There are refs, heads, objects, and blobs, and not all of those have the same operations (list, show) defined on them. There are changesets but also snapshots. Why do some commands have a --porcelain flag and others don’t? Did you know Git has garbage collection? You can’t rename a file in Git. What’s the difference between branches and tags? These are all things that are really discovered only through relentless trial and error.
      - seba_dos1 4y ago
        I never dug into git tooling, I'm a mere git user - yet I knew most (not all) of these. Some of those actually make intuitive sense. And some of those don't really matter in regular usage, since it's not the actual on-disk data structure you need to be concerned about when working with git, but only parts of it that actually create the useful abstraction. Everyone seems to be learning git by staging and committing some code, then making pushes and pulls, with all the rest added on top of that. Basically, learning the UI first and only then figuring out what that UI actually does. I'd rather advice to start by learning what refs are and how commits actually look like on a imagined repository graph, since that (along with the working tree) is what you're actually manipulating most of the time - all the rest flows quite naturally from that. Merges and rebases are quite simple from that point of view, and the way heads, branches and tags work make perfect sense then. Objects and blobs can mostly be perceived as implementation details, but once you realize that there are no actual changesets in git at all, they quickly stop being obscure as well (and then the fact there's no such thing as file rename becomes obvious too). And when it comes to garbage collection, git lets you know that by itself on a big enough repo ;) When you start learning the UI already equipped with that knowledge, it simply makes much more sense. Git's biggest sin is not having a clear separation between the abstraction it presents to the user and what's essentially its internal implementation. It's like an UI made for people who not only work with git, but also on git. The result is poor UX, which is why you need to learn what git does first before learning its UI. But poor UX doesn't mean it's rocket science - it only means that you'll have a better time learning from an external resource. Clean and smudge filters seem interesting, I wasn't aware of them, thanks for mentioning that!
      - everybodyknows 4y ago
        > You can’t rename a file in Git. $ git-mv <old_name> <new_name>
        ironmagma 4y ago
        That will produce an add plus a deletion. Whether or not this is considered a rename is up to git-diff, via the -M flag which specifies a “similarity index”. Side note, this doesn’t work with LFS-tracked files. But, with regular files you can say, e.g. you want the similarity index to be 50%, and then any files that were deleted that match 50% of their contents with another add will be displayed as a rename. So it’s really just a view thing. In the underlying storage, there is no such thing as a rename.
- bdangubic 4y ago
  your heart is in the right place but for many engineers there are ~20 tools that we use daily and we pick tools in most cases specifically based on "do they work" and "do I need PhD to get them to work" if I need to know how the tool works that that tool has already failed miserably!
- apeace 4y ago
  Are you amazed that the people who use the software you build use it without understanding the underlying data model? Probably not, because you understand that the reason you make software for them is so they can use it, instead of manually doing all the underlying steps your program does for them. Just because a tool is intended for engineers doesn’t mean it isn’t “hard” if it requires way more learning than any other tool in that engineer’s tool chain. Git is hard, even if you happen to have mastered it by now.
- throw0101a 4y ago
  > It amazes me the amount of engineers who can use a tool every day yet remain not the least bit curious to its basic internal operation. And how many of them use word processors and/or spreadsheets and don't bother learning about the internal structures of file formats? * https://en.wikipedia.org/wiki/Microsoft_Office_XML_formats https://en.wikipedia.org/wiki/Microsoft_Office_XML_formats Have you ever examined the bitstream of gzip or the structure of tar, even if you downloaded source file in them? Do you know the structure of RPM and/or Deb packages (depending on your favourite distro)? Do you know the voltage pattern of the Ethernet signals that go down the cable (or waveform of the Wifi / LTE radio signal)? There are only so many hours in the day, and not everyone wants to (or has the time) to go deep into every rabbit hole.
  - unicornmama 4y ago
    Consider that there’s a simple heuristic to prioritize where you drill down. That heuristic is pain.
sam_bristow 4y ago
One of my current projects at $DAYJOB is teaching literal rocket scientists how to use git effectively.
- unicornmama 4y ago
  This deserves its own hackernews thread :)

It amazes me the amount of engineers who can use a tool every day yet remain not the least bit curious to its basic internal operation.

ironmagma 4y ago
Perhaps it is that they actually are curious, but the amount of knowledge to be had is quite substantial.
- seba_dos1 4y ago
  I don't think that's the case with git though? It's fairly simple actually. The biggest (only?) challenge is to not view it as a tool to do versioning of your code, but rather a tool to work on data structures that effectively do versioning of your code. It seemed fairly straight-forward to me once I did that mental shift.
  - ironmagma 4y ago
    Everyone says that, but I don’t find it to be true. For context, we run a Gitea fork at work, and I often have to read the source code inherited from upstream Gitea. There are a ton of things that can happen during a merge, for example. Does anyone know what a smudge filter actually is? Why are there branches, and also tracking branches? There are refs, heads, objects, and blobs, and not all of those have the same operations (list, show) defined on them. There are changesets but also snapshots. Why do some commands have a --porcelain flag and others don’t? Did you know Git has garbage collection? You can’t rename a file in Git. What’s the difference between branches and tags? These are all things that are really discovered only through relentless trial and error.
    - seba_dos1 4y ago
      I never dug into git tooling, I'm a mere git user - yet I knew most (not all) of these. Some of those actually make intuitive sense. And some of those don't really matter in regular usage, since it's not the actual on-disk data structure you need to be concerned about when working with git, but only parts of it that actually create the useful abstraction. Everyone seems to be learning git by staging and committing some code, then making pushes and pulls, with all the rest added on top of that. Basically, learning the UI first and only then figuring out what that UI actually does. I'd rather advice to start by learning what refs are and how commits actually look like on a imagined repository graph, since that (along with the working tree) is what you're actually manipulating most of the time - all the rest flows quite naturally from that. Merges and rebases are quite simple from that point of view, and the way heads, branches and tags work make perfect sense then. Objects and blobs can mostly be perceived as implementation details, but once you realize that there are no actual changesets in git at all, they quickly stop being obscure as well (and then the fact there's no such thing as file rename becomes obvious too). And when it comes to garbage collection, git lets you know that by itself on a big enough repo ;) When you start learning the UI already equipped with that knowledge, it simply makes much more sense. Git's biggest sin is not having a clear separation between the abstraction it presents to the user and what's essentially its internal implementation. It's like an UI made for people who not only work with git, but also on git. The result is poor UX, which is why you need to learn what git does first before learning its UI. But poor UX doesn't mean it's rocket science - it only means that you'll have a better time learning from an external resource. Clean and smudge filters seem interesting, I wasn't aware of them, thanks for mentioning that!
    - everybodyknows 4y ago
      > You can’t rename a file in Git. $ git-mv <old_name> <new_name>
      - ironmagma 4y ago
        That will produce an add plus a deletion. Whether or not this is considered a rename is up to git-diff, via the -M flag which specifies a “similarity index”. Side note, this doesn’t work with LFS-tracked files. But, with regular files you can say, e.g. you want the similarity index to be 50%, and then any files that were deleted that match 50% of their contents with another add will be displayed as a rename. So it’s really just a view thing. In the underlying storage, there is no such thing as a rename.
bdangubic 4y ago
your heart is in the right place but for many engineers there are ~20 tools that we use daily and we pick tools in most cases specifically based on "do they work" and "do I need PhD to get them to work" if I need to know how the tool works that that tool has already failed miserably!
apeace 4y ago
Are you amazed that the people who use the software you build use it without understanding the underlying data model? Probably not, because you understand that the reason you make software for them is so they can use it, instead of manually doing all the underlying steps your program does for them. Just because a tool is intended for engineers doesn’t mean it isn’t “hard” if it requires way more learning than any other tool in that engineer’s tool chain. Git is hard, even if you happen to have mastered it by now.
throw0101a 4y ago
> It amazes me the amount of engineers who can use a tool every day yet remain not the least bit curious to its basic internal operation. And how many of them use word processors and/or spreadsheets and don't bother learning about the internal structures of file formats? * https://en.wikipedia.org/wiki/Microsoft_Office_XML_formats https://en.wikipedia.org/wiki/Microsoft_Office_XML_formats Have you ever examined the bitstream of gzip or the structure of tar, even if you downloaded source file in them? Do you know the structure of RPM and/or Deb packages (depending on your favourite distro)? Do you know the voltage pattern of the Ethernet signals that go down the cable (or waveform of the Wifi / LTE radio signal)? There are only so many hours in the day, and not everyone wants to (or has the time) to go deep into every rabbit hole.
- unicornmama 4y ago
  Consider that there’s a simple heuristic to prioritize where you drill down. That heuristic is pain.

sam_bristow 4y ago

One of my current projects at $DAYJOB is teaching literal rocket scientists how to use git effectively.

unicornmama 4y ago
This deserves its own hackernews thread :)