Re: Teaching the fourth “r:” webmaking as a vital 21st century skill

Thanks a lot for this response Brennan, and sorry it took me so long to read it.

So basically we need to think more about how to present this course in a "here's how to think to use these technologies to solve any problem you come across" kind of way , rather than just "here's how to solve a specific set of common problems using this technology" kind of way.

The latter is easier to do, but it is way worse for learning and autonomy.

the former is a lot harder to teach, and I don't have all the answers yet on how we apply this to our material. Maybe we need some kind of extra set of articles on how to think to solve problems with code? Going to back to using paper and pen to sketch ideas and write out steps, and then looking in detail at the cognitive process necessary for translating your requirements for solving a problem into code.

"I want my program to do A"
"To do A, the logical steps I would take are B, C, D, E and F"
"I can do these using the following code constructs"
"Here's the start data I need"
"Here's how to manipulate it into what I want"
etc.

I'll think more about this, going forward. Any more thoughts or responses?


Chris Mills
Open standards evangelist and dev.opera.com editor, Opera Software
Co-chair, web education community group, W3C

* Try Opera: http://www.opera.com
* Learn about the latest open standards technologies and techniques: http://dev.opera.com
* Contribute to web education: http://www.w3.org/community/webed/

On 21 Feb 2012, at 10:06, <brennan@young.net> <brennan@young.net> wrote:

> This is also my hobby horse: Teaching how to *think about* making digital stuff. And sanity is relevant here. (Too many of the pioneers of our trade went crazy and committed suicide!)
> 
> Well, I would go further; Computers (and programming environments) are extensions of human minds, so we need to identify how digital process resembles thinking. There are also (crucially) many areas where they differ. Digital process tends to be modelled on the minds of computer scientists, who take abstraction for granted.
> 
> Experts too often become experts by forgetting what it was like not to know things, and then become poor teachers because they come to believe it's easy.
> 
> Unfortunately, courses and curricula will tend to center on techniques - a sort of 'cookbook' approach, or will teach the stuff the way the expert already understands it. Cookbooks are very handy when you have passed a certain threshold, but they are also limiting. They show disconnected arcs of circuits, but never the complete circuit. The dish, not the meal.
> 
> So the trap tends to be a cultivation of the attitude: Do A, B and C in that order and you will get D. Every time.
> 
> Example misconception: "PHP generates HTML". Not necessarily so. When I pointed out to a small group of students that PHP could also be used to generate javaScript or CSS, or even images, sounds and videos, they looked at me like I was crazy. (Or was it their own craziness they could feel creeping upon them?) So I showed it working, and then I could see several of them falling into some kind of OMG trance.
> 
> I think there's a need to approach coding as a kind of gardening. The code is not made of lego bricks which can be put together willy-nilly. Attempts are made to do this, which is why frameworks and engines are so popular. But it's false, like in the middle ages, a generic drawing of a tree was all you would ever need to represent any tree in any picture. In the renaissance, the artists decided that all trees were unique, look different, and should be drawn as such. They studied light, shadow and perspective instead of "what trees are like", and could apply those same principles to other objects.
> 
> Likewise, the code has to grow, and somehow assemble itself, uniquely, through communication with the programmer. The programmer nurtures the code, clipping off branches which grow in the wrong direction (whatever that means) and encouraging attractive blooms (whatever that means) in the right places (whatever that means). There are absolute value judgements and even heresies with any piece of code. Therefore there are multiple algorithms on the way to the finished algorithm, each one slightly less 'wrong' than the previous one.
> 
> "Change the environment to its opposite and every piece of wisdom becomes the worst of folly"- W.R. Ashby
> 
> So the code is a kind of artifact or record of a conversation between the programmer and the system (IDE or whatever), made in a given context.
> 
> The teaching material should not merely say "do this" it should say "look at that, what do you think it means? Is that consistent with what you know or where you are heading? At what point can we abandon it? When would that be unsuitable?"
> 
> But it is the programmer who has to add branches which may eventually be lopped off. How could a novice be motivated to do something like that? They're still struggling in the paddling pool of syntax errors!
> 
> I found myself very inspired by this talk by Bret Victor (1 hour long): http://vimeo.com/36579366
> 
> The w3schools site deserves a legal kick up the arse for appropriating the w3 name unofficially, making no effort to emphasise their third-party status, stuffing their site with ads, and allowing so many inaccuracies, but it is quite well-organised by 'recipe', topics are easy to find - and their best feature is a quite primitive "try it yourself" gadget which allows you to get beyond recipes and into immediate experiment. It would be useful to discuss whether we could introduce something similar (and better!), perhaps inspired by Bret Victor's elaborate demos.
> 
> 
> A final comment on the new javaScript outline on the wiki. I *really* like what I see there, and I am eager to start 'breaking' the existing material into parts which will fit the new outline.
> 
> 
> 
> On Feb 20, 2012, Chris Mills <cmills@opera.com> wrote:
> 
> It's a shame I missed this (I was on vacation). I completely agree with the salient point here. You can teach technology syntax and graphic design skills until you are blue in the face, but people still won't get it unless they really start to get how to solve a problem with CSS or JavaScript. But how to teach that in any kind of sane way? From my experience, to get into this mindset it takes a good few years of experience, messing around with the technologies, and looking at what others have already done.
> 
> Thoughts?
> 
> Chris Mills
> Open standards evangelist and dev.opera.com editor, Opera Software
> Co-chair, web education community group, W3C
> 
> * Try Opera: http://www.opera.com
> * Learn about the latest open standards technologies and techniques: http://dev.opera.com
> * Contribute to web education: http://www.w3.org/community/webed/
> 
> On 14 Feb 2012, at 23:09, Janet Swisher wrote:
> 
> Members of this group may be interested in this online event:
> http://lanyrd.com/2012/CathyDavidson/
> 
> Unfortunately, it's rather late in the evening for those in Europe.
> 
> (If you didn't follow the link, the "fourth 'r'" is algoRithms.)
> 
> This brings up an important point: it's not enough to teach Web technologies; we need to teach how to think about working with those technologies. 
> 
> -- 
> Janet Swisher
> Mozilla Developer Network
> Technical Writer/Community Steward
> 

Received on Monday, 27 February 2012 11:36:14 UTC