Yesterday our Kids Code Jeunesse founder and chief badass Kate Arthur chatted on Montreal local tv with Richard Dagenais. Great interview — I think Kate did a good job positioning code as a common everyday medium that anyone can (and ought to) get a taste of and put to use, even without becoming a programmer. And maybe some folks in the audience will come away a little less intimidated by learning to code.
Cited in the interview: our partner codecademy, who has a great lineup of well-documented, self-paced lessons in a variety of coding platforms. (Seriously, check out their HTML + CSS sequence. It’s not perfect, but they align well with my axioms of programming instruction. It’s a very good entryway for kids and newcomer adults.)
The Education seminar I’m enrolled in right now is a lot of fun, but is occasionally mind-bendingly self-referential.
It’s easy enough at the surface level: we (a mix of MA and PhD students) are learning what makes teachers effective. The trick is that we’re working on this practice NOT in order to teach K-12 students, but in order to teach teachers.
Here’s a fascinating take on the STEM imbalance from University Affairs: the major dynamic may not be sexism or any other institutional intent, but the accumulation of simple economic choices at the individual level. And the solution may be more background than foreground. Intriguing, no? Continue reading Male-female imbalance in STEM comes down to economics?→
The conversations I tend to be involved in about underrepresentation in the technology world are about the gender divide. At Kids Code Jeunesse we’re very conscientious about designing our activities and honing our pitch so we include girls. And in my own reading and thinking (probably colored by who my 2 oldest kids are) I pay particular attention to the ways we can make technology and “computational thinking” accessible to girls.
There’s lots of interesting stuff to think about there: which applications of tech are likely to appeal to girls (and yeah, they are different than for boys); how to teach in a way that resonates with the expressive side of a kid, rather than the purely rational side; and more.
But of course there are other divides too, and here’s a great story out of Baltimore about a year-round code camp directly targeted at minority boys: the Minority Male Makers Program(via npr.org). It’s being rolled out at a handful of Historically Black Colleges in the American south that have engineering schools: Morgan State U., North Carolina A&T State U., Jackson State U. and Kentucky State U. as of summer 2015. Guided by undergrad students at those schools, these kids get to design, engineer, 3-d print, and code their own ideas and products.
They’re reaching kids at middle school age. They rightly point out that this is their last shot at reaching kids before their path toward adulthood (and higher education and professional life–if any) starts to solidify and accelerate. Influence them here, show them it’s possible to be creative and use their brains for good, hard things, and you stand a good chance of influencing their choices in next few years. And then they’ll be on a good, productive path.
They’re letting the kids make real things starting right now. With programming, modelling software, and 3d printers in the classroom, this is tinkering with real stuff. Look at the press release and see that these kids are walking out of the classroom with the objects they’ve made. There is no 4-year lecture-driven book learning period, no extended apprenticeship standing between their adolescent selves and being real-world-productive.
They’re looking specifically for kids who show signs of being disengaged and bored in class. They know that disengagement isn’t a sign of being stupid; it’s a sign of needing a more active, hands-on learning method than the school is set up to deliver.
And the NPR article suggests that, rather than opening it up for open registration, they are asking school principals and counselors to bring them students. This is a great way to (1) encourage administrators who are engaged with their students and know them well, and (2) sidestep the self-selection that attracts self-motivated geeky boys to code camps. We have plenty of those already.
Bootstrapping the talent pool
I love seeing programs like this, and the overall philosophy is what attracted me to the Kids Code Jeunesse team. All programs of this kind are trying to bootstrap the tech talent pool in a very conscious way. Malcolm Gladwell might say these are ways to solve our talent selection problem, our “quarterback problem.”
If we want to change the complexion of the tech industry and what it produces, it will have to be through initiatives like this: initiatives that intentionally reach everyone, or that intentionally reach underrepresented groups.
If we can keep those going, the tech industry will not only look different in its makeup and its atmosphere; it will start producing output that’s better and that speaks to a wider range of people.
Introducing…. Mike’s Axioms for Computing Instruction.
As I do more and more teaching and lesson writing, I’ve started collecting the gemmiest of my design principles.
Little by little I’ll record them here in the blog with some examples and the reasoning behind them, and hopefully they’ll be a useful reference for me and others. As I deepen my formal knowledge and gain more hours of practical experience, I’ll come back and elaborate or revisit.
The week of May 17-24, 2015, students from across the US are invited to play a (everyone outside the US too, but they’re not eligible for prizes). Challenges include cryptography, reverse-engineering, and reconnaissance. Continue reading CS Capture the Flag 2015→
One of the things they get most excited about–especially, he says, the girls–is cryptography. They think it’s really cool that they can use their just-beginning programming skills to reverse-engineer passwords and crack codes and stuff like that. Continue reading Crypto for high schoolers→
I would personally skip the two about higher ed “disruption,” since nobody really knows how much of that (for-profits, MOOCs, finance/tuition reform, etc.) will stick—and, frankly, the blurbs are an embarrassing mix of hype and misunderstanding. From The End of College, for example: will the “traditional meritocracy” really be “upended” in the end? Who would describe the US college system as a “meritocracy” in the first place? It just goes downhill from there…
Some more promising books on this list, by my own reading of the descriptions:
Today was the first time I’ve ever come across the term “STEM” out in the wild, in a context that wasn’t purely Educational. It was in a technical job posting, and I think it’s an interesting “leak” of Education terminology into the professional world. Continue reading STEM in the wild→
Note the use of the past tense. You gotta love trolling for Java apologists.
To be fair, you gotta love trolling for Python believers too. The difference, of course, is that the Python believers are usually right.
If you read the Answers, there are some very thoughtful critiques . The best of them seem (my favorite is by Joe Wezorek) to conclude that Object Orientation is a useful way of thinking about certain things – but maybe is a relic of the past, developed as a good response to the specific kinds of software problems that were prevalent in the 1980s, and probably gets used too abstractly and too blindly to be called good practice.
Another good response (by John Colagioia) appreciates the fact that Object Orientation provides some useful scaffolding: “You might not end with a great design, but you can have a passable design if you ‘implement every noun as an object, every verb as a method, every adjective and adverb as a condition.'” I can get behind that.
But the over-abstraction that we see in some languages–and really, this may just be because it’s being poorly understood and taught–is a real stumbling block to having more people become coders, and having our existing coders be expressive with their work.
My own opinion is that the over-abstraction may just be a natural interaction that happens when engineering meets the corporate business world. You end up with people who think a certain way about process and content and how they should work in the world, and before you know it, you’ve got a gospel that turns an otherwise creative, dynamic act (programming) into an exercise in over-architecture and bloat.
But my favorite bits are still the ones where the Java folks get teased.