4 ms·

I’ve only taught a handful of people to build software, but what I’ve seen is there is a world of difference between writing words and dragging encased blobs ar

I’ve only taught a handful of people to build software, but what I’ve seen is there is a world of difference between writing words and dragging encased blobs around. One person in particular has a real knack for breaking problems apart and understanding them. He could explain things really well that demonstrated understanding, but converting that understanding into the syntax the compiler would accept was an enormous barrier. He overcame it with time and practice and that was so exciting to see for them. Could they have learned faster or differently with something like blockly? I don’t know. I’d like to think so. You are right, you look past the coloured blobs you are doing the same thing, but for some people at least the syntax and keywords can be an enormous barrier. I suspect even more so for not-so-frequent developers

haswell 5y ago
> but for some people at least the syntax and keywords can be an enormous barrier. I suspect even more so for not-so-frequent developers This is the key thing. I think it's hard for developers to remember what it was like to not have this skill that allows them to take a problem, translate that problem into code, and then use code to solve it. I think devs (because most of us love to write code) also forget that the end goal isn't to write code, it's to solve the original problem. This bias makes it harder to see the value of a visual tool for the non-dev. When you think about code as a solution to a problem as a non-dev, something like this emerges: - I have a problem/question I want to solve/answer - It can be solved using code - I don't understand code (yet) - Now I have two problems: 1) The original one (the one that matters) 2) I don't understand code In order to make any progress on the thing that matters, I have to also make progress on literally learning a language. A reasonable objection to this might be "but the user still has to learn the low code tool", and this is fair. But the #1 thing that low code tools bring IMO is: Discoverability. In a visual tool, I can see and try things. Blockly makes this explicit by showing you where and how things can be connected using visual language almost everyone already understands (puzzle pieces). That same kind of experimentation is only possible in code once you understand the syntax, but first you must understand the syntax, and before you understand the syntax, fight through syntax errors, interface compatibility, etc. The chances of abandoning the effort altogether are pretty high. Thinking about learning more generally, visual aids are almost always at the center of the teaching process. The very earliest thing almost every human learns: spoken language - also involves a learning period where the child might first point at a picture/object, later say the word, and even later, learn how to write that word. Even after understanding a language fully, humans still point at pictures to communicate on a regular basis to optimize the communication process. Just look at your local fast food restaurant's menu. Too often, no code tools are evaluated as if they must be "better" or "worse" than code. But these evaluations are asking the wrong questions and fundamentally miss the reason these tools exist to begin with.
- phil-martin 5y ago
  Thank you for articulating that so clearly, it echoes my thoughts very strongly. I agree, they are asking the wrong questions. I have spend more more time than I care to think about in front of a text editor trying to coerce computers into doing what I want. The sheet volume of information I need to know to be productive often makes me shy away from recommending this career path to others. And I wish your example was how things really were. If only the second problem was learning code. The gap from not knowing code, to knowing enough code, tooling and how to do things to solve a real world problem is so dauntingly large. Even the concept of that a variable can change value inside a loop is so mind-bendingly hard to get ones head around and so abstracted from the real problem they're trying to solve. But a discoverable visual canvas where you can SEE things fitting together, and the little notches meaning only the right types of blocks can fit together like lego. So useful for bringing problem and solution closer together.

haswell 5y ago

> but for some people at least the syntax and keywords can be an enormous barrier. I suspect even more so for not-so-frequent developers This is the key thing. I think it's hard for developers to remember what it was like to not have this skill that allows them to take a problem, translate that problem into code, and then use code to solve it. I think devs (because most of us love to write code) also forget that the end goal isn't to write code, it's to solve the original problem. This bias makes it harder to see the value of a visual tool for the non-dev. When you think about code as a solution to a problem as a non-dev, something like this emerges: - I have a problem/question I want to solve/answer - It can be solved using code - I don't understand code (yet) - Now I have two problems: 1) The original one (the one that matters) 2) I don't understand code In order to make any progress on the thing that matters, I have to also make progress on literally learning a language. A reasonable objection to this might be "but the user still has to learn the low code tool", and this is fair. But the #1 thing that low code tools bring IMO is: Discoverability. In a visual tool, I can see and try things. Blockly makes this explicit by showing you where and how things can be connected using visual language almost everyone already understands (puzzle pieces). That same kind of experimentation is only possible in code once you understand the syntax, but first you must understand the syntax, and before you understand the syntax, fight through syntax errors, interface compatibility, etc. The chances of abandoning the effort altogether are pretty high. Thinking about learning more generally, visual aids are almost always at the center of the teaching process. The very earliest thing almost every human learns: spoken language - also involves a learning period where the child might first point at a picture/object, later say the word, and even later, learn how to write that word. Even after understanding a language fully, humans still point at pictures to communicate on a regular basis to optimize the communication process. Just look at your local fast food restaurant's menu. Too often, no code tools are evaluated as if they must be "better" or "worse" than code. But these evaluations are asking the wrong questions and fundamentally miss the reason these tools exist to begin with.

phil-martin 5y ago
Thank you for articulating that so clearly, it echoes my thoughts very strongly. I agree, they are asking the wrong questions. I have spend more more time than I care to think about in front of a text editor trying to coerce computers into doing what I want. The sheet volume of information I need to know to be productive often makes me shy away from recommending this career path to others. And I wish your example was how things really were. If only the second problem was learning code. The gap from not knowing code, to knowing enough code, tooling and how to do things to solve a real world problem is so dauntingly large. Even the concept of that a variable can change value inside a loop is so mind-bendingly hard to get ones head around and so abstracted from the real problem they're trying to solve. But a discoverable visual canvas where you can SEE things fitting together, and the little notches meaning only the right types of blocks can fit together like lego. So useful for bringing problem and solution closer together.