> knowledge makes it hard to comprehend the difficulties other people have

The phenomena you describe is known as the Curse of Knowledge [1]

Wikipedia gives an example: A knowledgeable professor might no longer remember the difficulties that a young student encounters when learning a new subject for the first time. [2]

[1] https://academia.stackexchange.com/q/163747/132074

[2] https://en.wikipedia.org/wiki/Curse_of_knowledge

The skillset to navigate this is one of the underappreciated challenges of teaching.

Exactly zero of my mathematics professors, and a large portion of my CS professors managed to adequately account for this. The professors of mine who did manage it remain firmly in my memories as great people and great teachers, while the one's who didn't inhabit an area between complete memory erasure, and disdain for how hard they made my life. This is at the very core of what it means to be a teacher, not just knowing the material, but knowing how to teach the material. I consider many of them to be failures at their main job for failing to navigate the curse.

> In the middle of delivering a lecture, Hardy arrived at a point in his argument where he said: "It is now obvious that..." Here he stopped, fell silent, and stood motionless with furrowed brow for a few seconds. Then he walked out of the lecture hall.

> Twenty minutes later he returned, smiling, and began: "Yes, it is obvious that..."

> I consider many of them to be failures at their main job for failing to navigate the curse.

A professor's main job is not to teach. It's publishing and getting funds into the university.

> I always find it interesting how knowledge makes it hard to comprehend the difficulties other people have.

Once the mind had bootstrapped itself to a concept, it is very hard to empathize with your past self unless you took cares to document the difficulties while still in the confused state, articulating as much detail and as many fallacies encountered as possible.

I always liken it to Wittgenstein's analogy -- don't throw away the ladder after having climbed up upon it!

> Is it common that developers still have issues with git after using it professionally for a couple of years?

As someone who has worked on developer tooling, including building a custom git client at a former job - yes.

Most people learn a few specific workflows not conceptually how things work under the hood.

Visual editors like GitKraken, Submlime Merge, Sourcetree, etc, have made this much better but there's still a big gap.

I can do git pull, branch, add, commit, push, merge, diff, status, stash pretty much without thinking but much beyond that I have to look it up.

> Admittedly, I still have trouble remembering the commands to do what I want (hello, rebase --onto A B C), though :P.

I work at a company where every developer uses Sourcetree, a GUI for Git. I don't really have a need to remember Git commands (and what arguments they take) anymore after using a GUI. For me, it is sufficient to know what Git commands do without knowing the semantics.

I always use SmartGit, another GUI. (I've lauded it to all and sundry, but have yet to inspire a new devotee...)

I understand the commonly used core concepts of git pretty well, and using that knowledge, I can do exactly what I want using Git GUIs (IntelliJ these days). With CLI I can do pulls and commits at most.

IntelliJ has become pretty powerful with Git these days.

Squashing, dropping commits, rebasing. Even interactive rebase can be done in a few clicks.

I sometimes pop up IDEA to do some non-trivial cleanup in a repo. Even if relatively fluent with the command line, it saves me a lot of time.

What I like most, and isn't available in most UIs, is the ease of selecting individual lines you want to commit. Allows you to make very clean isolated commits most of the times.

Magit does that and this is super useful indeed!

I can confirm the part about rebase workflow, it really forces you to understand the git model. I sincerely recommend every dev to try it at least once. It also got me into custom power tools for git, like incremental rebase, dual blame, etc.

Too late to edit but I just realized we probably mean very different things by "rebase workflow". I meant making extensive use of Git history editing even on public branches, (with tags serving as backup). I guess the common meaning of "rebase workflow" is just using rebase instead of merge.

Largely we rebase so that all PRs are defacto Fast Forward merges. Rebasing on publicly visible branches (PRs and the like) is common, although rebasing major branches (Master or a release) is not. We're small enough that we can get away with that if we must, though (usually if someone breaks something badly).

Basically, developers rebase all the time on their own branches, and rebase over their target branch (fixing conflicts) so that the PR is fast forward.

Agree on the git model thing, I feel like I have a reasonable idea of how git functions under the hood now, so I can figure out what most operations should do, even if I haven't used them before.

A version control tool shouldn't take YEARS of usage to be productive, to me that's a red flag. Some engineering tools are just complex because what we're doing might need that flexability so the tools provide a myraid of options or workflows.

But writing software, tracking your changes, being able to back out your changes and getting your changes integrated into a code base should be as low activation energy as possible to be productive.

But again, git wasn't created for "you and me", it was created by one guy for his project, the fact "mere mortals" are using it is kind of our fault.