[cloogshicer]

I've been teaching programming to complete beginners for a few years now.

One of the things holding them back the most is being too afraid to admit when they don't understand something.

This is despite many efforts on our part to give them a safe environment where such an admission is not ridiculed, but congratulated instead.

I really wish that culturally, we all were more kind when people openly display confusion, misunderstanding, and errors in thinking.

[jvans]

This holds back people of every level. Paradoxically I think it holds senior people back more because once someone gets a sufficiently senior label, they think they should have all the answers and stop asking questions

[em-bee]

oh, it's not that i think that i should have all the answers and stop asking questions, but when i feel that this is what others expect from me then the only place where i can safely ask questions is among others who are even more senior than me.

or another way to look at it is stages: thinking that i should stop asking questions is senior level one. once you outgrow that and advance to senior level 2 then you can ask questions again.

[amon22]

This is so very true

[readthenotes1]

There were some studies with firemen that showed the following technique was better than traditional teaching:

1. Explain/demonstrate right things to do. 2. Have the students criticize other people's work to find deviations. 3. Have the students do the work themselves.

That is: by looking at other people fail it takes the ego out of it.

[another_story]

Interesting, because as a former CS teacher I regularly did this. We'd go through some material and then I'd demonstrate it being used in different contexts, sometimes writing code that wouldn't work and sometimes writing poor code (while loops that should be for loops, inconsistent variable names, etc...) and the kids dug pulling it apart. It's much easier to critique than to create when you're beginning coding.

On that note I've been giving a lot of thought lately on how to develop curriculum which does a better job of teaching coding skills without necessarily needing code. Design thinking, but at a smaller scale, and later translatable to beginner level problem solving. Where kids get hung up is they often don't have a toolkit for this type of thinking, and building that up, while still making it interesting, is a challenge.

[readthenotes1]

I did as well and believe my classes improved as a result.

I was taught "flow charting" as an attempt to teach coding without having to code. Of course, the teachers missed the point and forced template-driven syntactically correct charts that were more painful to build than the programs.

I have never taught software to complete novices, but I would think that it's difficult to teach something without teaching the thing. Have you tried the "wax on wax off" approach? That is, break things down into stunningly small pieces and build them together? You could spend days grounding on the fundamentals. (It works for training sports, rapid demonstrate/mimic/correct cycles on the basics)

[another_story]

I've tried something like what you're describing. Most years I'd start with a week or two of solving problems that don't involve any code at all.

For example, a day one teaser (these are 12 year olds) I liked to give was an 8 by 8 grid on the floor. They would get in groups and devise a way to move from a start to an end location. Then they would enact it, first me receiving their directions and later other students. I would of course take their directions a literally as possible, with them frequently getting exasperated ("that's not what I meant!").

We'd go from that to generalizing some rules and formulating steps. Once they had working rules, I'd add obstacles or change the start and end locations.

My goal with these was to develop the skill of seeing discrete, reusable steps, and how they mirror each other between problems. Learning loops and conditionals without ever writing coding, for example. Seeing the need for variables as storage, etc...

[roenxi]

As a beginner, they don't plausibly understand anything. Understanding functions and variables is a deep topic that can take years to master. If it is possible to truly understand them and assuming human knowledge has reached the point where we understand functions completely - I feel confident we've got variables although even then it is hard to be sure. And that covers all of programming! I suspect in a large number of cases "admit when you don't understand something" is useless advice because the problem is they can't identify discrete chunks of knowledge to practice.

[mcny]

Even today I don't fully understand what a bus really is. I mean I sort of get that it is one or more (copper?) wires that carry information as electricity somehow but at no point do I remember anyone saying this explicitly in any of my education.

I've had to piece this information together in my head from multiple conversations. So now when I hear the word bus, I think a ribbon cable. Each of those cables can only send two states, high and low current and that's how I think of a bus because anything more advanced isn't something I can intuitively process at all.

So I'll just nod and smile when people talk about bus and I don't understand a thing.

[layer8]

I mean, you could read https://en.wikipedia.org/wiki/Bus_(computing) or one of the first Google hits for “hardware bus”: https://www.computerhope.com/jargon/b/bus.htm

You can’t expect to learn stuff like this just from random conversations.