We had a romantic Valentine’s Day evening after school on a Friday night at Canada Learning Code’s HTML/CSS Valentine’s Card coding night. CLC offers a lot of coding experiences for people who haven’t done it before. You get a room full of volunteer experts who code all day for a living, which I found particularly interesting because I wanted to see how they solved problems.
The majority of people in the room had never looked behind the webpages they view every day, so the presentation started off with explanations of what Hypertext Markup Language and Cascading Style Sheets are (you’re using them now to read this). From there we all installed ATOM, an HTML/CSS editor, onto our laptops and got stuck in.
Coding can seem like an all or nothing proposition to people new to it. Unlike written language, if you have a single error in code the whole thing can become unrunnable with no clear reason why. Imagine writing an English essay and if you have a single grammar or spelling error the whole thing is nonsensical. That’s the challenge of coding, but there are some supports you can put in place that help you deal with this absolutism, and CLC introduces you to all of them.
The ATOM IDE (integrated development environment – like a word-processor for coding) colour codes your text as you’re typing and offers suggestions. It quickly lets you add and change what you’re working on. When you save your code in ATOM you pivot over to your browser and refresh your page to see what’s changed.
While coding is harsh when dealing with errors, a good IDE and that iterative approach of being able to quickly try something helps you work around those error landmines, but getting people into that mindset is tricky, especially after school where we tend to drive students toward one-try grading (quizzes, tests, exams, interviews, performances, pretty much everything we do in education). As a result students have learned not to iterate. If it doesn’t work at first you’ve failed, which is a disastrous approach to coding. Recognizing the value of the engineering process and iteration was the biggest single takeaway for me at this event.
At one point Michelle Mabuyo, the lead of the KW Chapter of Canada Learning Code, ran into a problem with the animations we were running on our websites. Without hesitation she immediately attacked the problem using the same engineering process I continually drill into my students. As she iterated attempts at fixing the problem she kept escalating her scale, eventually reverse engineering the error out of the code from a known good, working program.
Watching someone who is good at something turn it on and do their thing is something I really enjoy. Michelle wasn’t aiming to put on an engineering show, this was supposed to be a gentle introduction to web development, but an error made her kick it up a gear and engineer a solution in real time. My best seniors get to this point by the end of high school, and when they do I know they’re ready to tackle whatever post secondary is going to throw at them.
At one point Muhammad, a software engineer from Google who was volunteering at this event, came by to see how I was doing. He doesn’t spend any time in HTML at Google, but once you understand how code works, you can move laterally into other languages quite quickly. I was trying to do something with the falling hearts animations that was a bit beyond the instructions, so he said what I always say, “look it up!” I told him about the Futurama Fry meme and he laughed because he has a copy pinned up by his desk… and he’s a software engineer!
That self deprecating piece is something that people who are good at something tend towards. The cocky types tend to be way back in the Dunning-Kruger effect. People who are good at something tend to be aware of how difficult it is and are more likely to take a more humble approach.
I really enjoyed our nerdy Friday night Valentine’s Day at Canada Learning Code. I always doubt myself coming in to something like this (my comp-sci teacher did a number on me in high school), but coding (at least when you’re doing it as something other than an academic exercise) isn’t about mathematical perfection, though that was how it was portrayed in my high school comp-sci classes before I dropped them. Coding is an applied process; it’s about an experimental, agile, iterative mindset and never taking your eye off the goal of a functioning solution. From that point of view, coding is little different than tuning the carburetor on my motorcycle.
I have no doubt that I could get more fluent in coding, but it’s a small part of the many subjects I juggle when teaching Ontario’s vague and encompassing computer engineering curriculum. In the meantime, I’ve got the agility and experience to quickly find solutions and modify them to work, and I need to acknowledge those skills. From that I could quickly develop the familiarity with coding needed to do it with less lookup. As a goal for my students, that’s an achievable, applied target, and not something to be ashamed of.
As we were wrapping things up another of the volunteers came by and commented on how much he liked the flip-card 3d effect in HTML. I asked him how it worked and you can guess what he said… look it up! So I did, and was able to get it working in about 5 minutes at the end of the session.
Coding is an opportunity to take risks and not worry about failing because iterating your way out of a problem is the solution. I only wish more computer science teachers would take that approach in Ontario classrooms.
If you get a chance, go to a Canada Learning Code workshop. They have specific meetings for girls, kids, women, teachers and teens, so you can always find a comfortable fit.
At the end of this particular meeting they also offered some pathways for people looking for a career change, which is a whole other angle to this. Coding familiarity is a vital employment skill these days.
from Blogger https://ift.tt/2V2NxzJ
via IFTTT
