"just how hard it is to get decent at programming"
We can improve that with: "to get (and stay) decent". I'm getting older, and it is so hard to keep up with changes. The async (coroutine) revolution in several languages in the 5-10 years was one of the hardest hills to climb ("WTF? How do you debug this sh-t!?").
Your comment makes me think about a blog post that I once read (I cannot find it now). Roughly, it was a list of things you need to learn as a computer programmer, but are not explicitly taught in classrooms.
One nice example: What is "staging" in Git? Hell, I've used Git for years now, and that part of my mental model is _still_ fuzzy, but the model is good enough to do my job well. I cannot know everything crystal clear.
I would the same for concurrent programming. Not looking down upon anybody, but the vast majority of programmers will never go deeper than: "Oh, just use a thread/worker pool with a runnable to do work." I've gone deeper, but blew off both my feet several times! (Hat tip to in/famous C++ quote.) And I only need to write concurrent code a couple times a year. I'm always rusty when I get back into it.
> One nice example: What is "staging" in Git? Hell, I've used Git for years now, and that part of my mental model is _still_ fuzzy, but the model is good enough to do my job well. I cannot know everything crystal clear.
You may have heard this one before, but staging is just saying, on your local filesystem, of all the files I've changed in this repo since last commit, these are the files I want to add into my next commit. You mark them for this with `git add <filename`.
(Slightly more detail: it doesn't need to be file-level; you can stage only certain changes within files if you like, using `git add -p <filename>`.)
Your comment makes me think about a blog post that I once read (I cannot find it now). Roughly, it was a list of things you need to learn as a computer programmer, but are not explicitly taught in classrooms.
One nice example: What is "staging" in Git? Hell, I've used Git for years now, and that part of my mental model is _still_ fuzzy, but the model is good enough to do my job well. I cannot know everything crystal clear.
I would the same for concurrent programming. Not looking down upon anybody, but the vast majority of programmers will never go deeper than: "Oh, just use a thread/worker pool with a runnable to do work." I've gone deeper, but blew off both my feet several times! (Hat tip to in/famous C++ quote.) And I only need to write concurrent code a couple times a year. I'm always rusty when I get back into it.