4 ms·

I think there's a tendency in our industry to forget just how hard it is to get decent at programming. All three of those topics you've listed are big, complica

I think there's a tendency in our industry to forget just how hard it is to get decent at programming. All three of those topics you've listed are big, complicated, and hard to get right. I have coworkers today who struggle to write code that isn't susceptible to race conditions. Before you even get to concurrent programming, there are a thousand other things you need to learn beforehand. Interns / juniors have little to no practical experience, and practical experience is where you _really_ learn how to program. I think there is room for innovation in CS/SE education. Imo some sort of "code review" class where students analyze and report on a bit of code would do wonders for interns / juniors ability to onboard quickly into their first job. I've written about this in the past [1] [1] https://sophiabits.com/blog/the-one-change-id-make-to-se https://sophiabits.com/blog/the-one-change-id-make-to-se

bobthepanda 4y ago
I think it would be hard to do, in a way that wouldn't end up sometimes being "the blind leading the blind." I remember in university we had peer review for writing courses, yet that didn't really seem to elevate anybody's writing more than it had been before. The people who did well continued to do so and the people who did not also continued to do so.
- sophiabits 4y ago
  That's a fair point :) I was quite fortunate to have university professors with a decent bit of industry experience, and I /think/ they likely would have been up to the challenge but that's far from the norm.
throwaway2037 4y ago
"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.
- robertlagrant 4y ago
  > 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>`.)

bobthepanda 4y ago

I think it would be hard to do, in a way that wouldn't end up sometimes being "the blind leading the blind." I remember in university we had peer review for writing courses, yet that didn't really seem to elevate anybody's writing more than it had been before. The people who did well continued to do so and the people who did not also continued to do so.

sophiabits 4y ago
That's a fair point :) I was quite fortunate to have university professors with a decent bit of industry experience, and I /think/ they likely would have been up to the challenge but that's far from the norm.

throwaway2037 4y ago

"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.

robertlagrant 4y ago
> 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>`.)