Sure, but I've never seen somebody try to read a book just to find that the book is written upside down and only reveals itself during the full moon.
How would somebody teach my wife to deal with a weird dependency error message? It took me several hours to figure out. Googling error messages accomplished nothing. There was no reasoning really behind it. Just unique problems with python dependency management. There aren't really transferrable skills here that would empower somebody to rapidly figure this sort of thing out if they just rearranged how their thought process worked. You either know the incantations or you don't.
Actually there are general techniques to troubleshooting. Like increasing observability of the system by increasing logging levels or via a debugger, figuring out expected behavior and looking for unexpected things, etc.
Here you'd just enable some way to see the dependency resolution process in more detail. What files are touched, etc. It can be as simple as running strace with an 'open' syscall filter, and you'd see some unexpected paths being touched, perhaps. But there are many ways to achieve the same.
How would she know about strace? It's just one of the tools you get to learn if you approach problems from the a generic "how'd I make what this program is doing visible to me?" when it's not doing what I expect. There are a ton of tools you learn if you approach problems this way over time, instead of searching online for error messages first.
These general techniques work for tech professionals. My wife is a historian. She needed to take a bunch of giant pdfs and split them into separate one page files. Easy enough to script with python. 10 minutes of coding. Hours of dependency hell.
So now in order to do some simple scripting I need to run strace and look for syscalls? Why would anybody just know this? Oh, and she has a windows machine. So this is precisely the sort of useless advice that is widely available online. "Don't worry, you can always just learn how your entire dependency management package works on the inside and interacts with your operating system if you run into problems scripting something for your job" is not helpful. It is the sort of thing that makes people flee screaming from the very idea of doing anything more general-purpose than excel.
> There aren't really transferrable skills here that would empower somebody to rapidly figure this sort of thing out if they just rearranged how their thought process worked.
Which is just false. There are transferable skills to achieve that.
Also troubleshooting is not the only way to achieve the goals. She could have just chosen a different tool, that doesn't come with a ton of baggage like Python does, if troubleshooting is too much of a bother. There are a lot of tools out there that could be used to select certain page range from pdf and save it as another pdf.
On Linux, I run:
pdfseparate InputFile.pdf InputFile-%d.pdf
and the job is done. I didn't even need to install anything. On Windows, all you need to do is just to find a way to install pdfseparate tool or an equivalent.
I guess I was unclear. The original post, which I was responding to, compared programming capability to literacy and described it as "the language of logic". The implication being that as long as somebody can learn to think algorithmically that they can use programming to solve their problems. My claim is that tooling is so terrible that "being able to think algorithmically" is not sufficient. Instead, you need to know all of this troubleshooting garbage.
When I said "there aren't really transferrable skills here" I mean that learning to think algorithmically will not transfer to being able to resolve these sorts of configuration problems.
Your final suggestion is similar here. Nothing about "learning to think algorithmically" helps you know that there is some tool already installed on linux that can do this. That's trivia, not logical reasoning. One can learn the trivia, but we should recognize that this is a necessary step towards making programming a daily part of many peoples' lives.
I agree that "learning to think algorithmically" will help someone apply programming language skills about as much as learning just English language grammar and very little vocabulary, will help someone apply English. Not much.
There's also workarounds as an alternative to troubleshooting.
Just change the CLI command that's failing to a function which `docker run`s the right thing with the rest of the params passed and be done.
But this assumes you know enough of your shell language to do that, and there will likely be things to troubleshoot there.
I've managed to avoid learning enough about OS internals to get a good handle on 'deeper' ways to troubleshoot like what you talk about with strace. Know any good resources to learn?
