Low/no code tools stove the wrong problem. The problem we should be solving is not the accessibility of code itself, but the accessibility of toolchains. The

Low/no code tools stove the wrong problem. The problem we should be solving is not the accessibility of code itself, but the accessibility of toolchains. The most confusing thing about learning to make software isn't writing a Hello World program or a Fibonacci series loop. It's figuring out what to do with that code once it's written. People don't interact with terminals and shells anymore, but guess what nearly every Hello World program is written for? A shell. We have a lot of tools that try to hide the toolchain, and even the shell itself, from the uninitiated developer. Unfortunately, hiding the complexity of the very system you are writing code for causes more problems than it solves. How can you learn to get input from the user if you don't even know how to use a shell? How can you start using libraries if you don't know where they are, or how they are distributed to the user? How do you configure the correct environment variables if you don't even know what shell you are running or how/where it was initialized? We should instead be doing the inverse: do everything we can to show new programmers the system they are using. Show them all the pieces of the puzzle, and how those pieces fit together, because our new programmer's primary goal is to make new puzzle pieces.