I think it is easy to see programming as the language of logic. But this is what I've observed as my wife has learned to use python, javascript, and R for her work.

The huge majority of errors have nothing to do with inability to think logically. Instead it is "I'm getting some incomprehensible fucking error message from conda" and it turns out the root cause is that her machine has multiple python installations and the places where dependencies end up installed are all fucked up and the solution has nothing to do with programming.

The second most common source of errors are "weird language things". Something can be expressed perfectly reasonably if you were to read it as pseudo-code but weird edge cases cause problems. Consider "==" vs "===" in JS. All sorts of fun issues there and it isn't really failing to understand "the language of logic" that causes people to bash their heads into a wall until somebody says "oh, JS has multiple ways of doing equality and you just need to know that".

The existing software ecosystems are nowhere near ready to support people who just want to think logically about problems and algorithms. It is just too filled with "wtf does PC_LOAD_LETTER mean".

I can see what you're getting at here, and perhaps "language of logic" is not the most accurate way to describe what software is. Maybe "language of complexity" or "language of systems" or something else. Someone could come up with better terms or metaphors here.

The difficulties you describe, however, assuming they aren't being caused by flaws or bugs, are part of the "language" we're talking about. I think one of your assumptions here is that logic is simple. That's true to begin with, but the software systems we build are usually towering arcologies of logic, with all manner of intricate, sometimes counter-intuitive details. A single detail, when examined by itself, is relatively easy to understand, but when taken together, they form a serious challenge for any human mind to grapple with. I think you could make comparisons to sprawling works of literature or advanced forms of mathematics, where the bits and pieces can be grasped, but the number of pieces, and the connections between them are often too difficult to see all at once.

  language of systems

that sounds about right to me.... and unfortunately, in my experience, most people (and alot of devs too) are not very good at systems thinking... but its an important skill to have!

Yeah - I think there's lots of bad tooling, but a lot of it does come down to logic.

Once people realize they're not doing something 'wrong' really and that it's just the tooling that's bad - they can start to understand that troubleshooting and debugging is most of what we're doing. Being good at troubleshooting and debugging is largely logic (isolating variables, testing, thinking about what it could be, knowing what to ask/search). It's why the dev joke of 'it works on my laptop' is funny.

The narrow scope of solving some explicit programmatic problem is one area where logic is needed, but debugging things is the more common use. Lots of historical things people had to debug are past that tooling stage and now mostly 'just work' (like compilers). Lots of newer technology is not close to that yet.

The analogy to literacy I think is a good one.

I wrote a little about this here: https://zalberico.com/essay/2020/04/19/how-to-become-a-hacke...

It's not like English and algebraic notation exist in the Platonic perfect state for their respective domains.

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.

So what? You said:

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

Yes. Makes sense. Thanks.

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?

I like this perspective.

It also hints at a potential resolution - Pull the team away from the technology for a little while so they can focus on the abstract problem domain.

Most developers probably don't have the capacity to think about shiny new technology while simultaneously running traps on the fundamental business domain abstractions. Taking time away from the computer to think about the problem you are actually trying to solve is a big deal. Many just get caught up fighting their own tools and lose sight.

One simple trick - If you are not yet at a point where you can cleanly model your problem domain in terms of SQL tables & relations (even if you don't intend to use this technology), you have absolutely no business touching the rest of the effort. There are notions that you can actually have a provably-correct model of your domain at a certain level. 3NF/BCNF schemas have fundamental mathematical implications that are very powerful. Entire classes of accidental complexity can be obviated with a clean domain model.

Yes. I think it is a Brooks quote that is something like "don't show me your code - I won't understand it, show me your database and I will understand your application."

Simple robust Data structures with complicated code acting on it.

"Show me your flowcharts and conceal your tables, and I shall continue to be mystified. Show me your tables, and I won’t usually need your flowcharts; they’ll be obvious." -- Dr. Fred Brooks

Could that word be computacy?