Category Archives: Codecademy

Code Year, Eighteen Months Later

Eighteen months ago, in January of 2012,  I decided to sign up for Codecademy’s Code Year. I wasn’t even sure what code was. But I had some time on my hands and an eleven year old son who was curious too. I was getting less and less work at the newspaper I’d been freelancing at for the last twenty years. And though I didn’t know it at the time, The Montreal Mirror was six months from folding.

In April, after I’d triumphantly (to me at least) familiarized myself with the fundamentals of JavaScript, I had a tiny twitter spat with Jeff Atwood over his now infamous post “Please Don’t Learn To Code.” Jeff, who runs the popular blog Stack Overflow,  didn’t believe that people should learn to code just for code’s sake.  He’d seen too much bad code, broken dreams, and faux programmers in his career to jump on the code learning bandwagon.

I get it. I’m a writer. I’ve heard many versions of this argument applied to writing (too many people taking writing courses to write books that nobody will read, etc.) Still, I have an intractable belief in the adventure of learning. So, I tossed off a counter post, which eventually made it into an e-book anthology, “Should You Learn To Code”, with other people who disagreed with Jeff.

When The Mirror  closed without warning, in June of 2012, it also closed fifteen years of archives, and a huge chunk of my professional portfolio. At least I had my blog. And even more free time. Before this employment crisis, I’d slapped together a little password creating app for for my son after his facebook account got hacked.  That was fun, so I’d signed up for Coursera/Stanford’s Human Computer Interaction course determined to get the studio track certificate in app prototyping.

By the end of July, I’d accomplished this (with distinction!).  I learned not just about design, but got some insights into the cognitive science that the top software engineers work with. I not only had a better idea of how apps work, but how the modern brain deals and doesn’t deal, with the constant potential for information overload.

Meanwhile,  back at Codecademy,  I was struggling through JQuery, hating the virtual checkers project, but doing it anyways. By the end of the summer, I still hadn’t figured out what I was going to do with all my new found functional literacy.  I couldn’t seem to settle on a particular project.

I discovered a Montreal enterprise, PressBooks, that had ingeniously hacked WordPress and turned it into a free multiplatform book writing app.  As an exercise in mastering it, I  wrote a first chapter and an outline for a book about my adventure in code. I’m not part of the kickstarter generation, so I went old school and wrote up a grant proposal for the Quebec Arts Council about a writer learning to code, trying to figure out her place in this new technologically complicated world.

This brought me to September when Codecademy introduced the Python track. I thought JQuery was tough, but it was nothing like the resistance I was feeling towards Python. My savings and credit were running out. Jeff Atwood was starting to make a lot of sense. What had I been THINKING, a middle aged single mother, learning code just for the sake of learning code.  Why was I still doing this?  I had no interest in being the relatively old lady at a start-up. I’m temperamentally ill suited to office work, so  I had no authentic desire to put these skills to practical use in the business world.  Every time I talked to another writer, or any  publishing professional, about what I was doing, they looked at me like I had lost my freaking mind.

I’d hit a wall. I could have so easily quit here. Not learn Python. No one would have been the wiser. But I’d gotten this far in my resolution. I needed to finish this marathon, or all the struggle I’d suffered through would be for nothing. So, I plugged away at Python, learning to, if not to love it, at least like it.

Until I got to list comprehensions. At which point, like anyone who has ever made it to list comprehensions, my mind opened. How could I not feel a tenderness towards this magnificent language, so ugly and incomprehensible  to everyone else, so elegant and rich with potential to anyone who understood it. On that day, towards the end of my code year, my grinchy writer’s heart grew to two sizes, and for a short while even my apartment seemed bigger.

Yes it bothered me, a lot, that for the first time in my twenty year career as a freelancer, I soon might not be able to make my credit card payments. But another part of me felt impenetrably calm. I remember an interview I once saw with Jada Pinkett Smith on Oprah, explaining why peformance anxiety never got to her as an aspiring teenage actress. She’d been to the High School of the Performing Arts, she’d work hard.  There was no reason to be nervous, she explained, because “I had a-bi-li-ties.”

No matter the stresses that seemed to be on the horizon,  I couldn’t seem to shake the confidence that inevitably comes with valued skills and knowledge. In mid-December, just as I got to the point where I thought I might be delusional, I got a letter informing that I’d received the book grant I’d applied for. Not the kind of money one would get for a start up. But the writing life has a pretty low overhead, so it was enough to keep me solvent for another year.

It was also around that time that I learned about the first meeting of Montreal Girl Hackers. It was at Notman House, a slightly dilapidated mansion in the heart of downtown Montreal that had recently been turned into a government subsidized tech incubator.  There were about thirty or so women of varying ages, backgrounds,  interests and skill levels, from computer science teachers to beginners. There was free beer and food, financed by Google and/or  Shopify, I’m not quite sure which.  We stood in a circle and talked about what had brought us here.  I told my story.  Everyone clapped.  It was lovely.

About  a month later I got an e-mail from the organizer. She’d remembered that I’d recently learned some Python and was wondering If I’d be interested in helping out at a weekend workshop organized by the Montreal Python community to teach women some introductory Python skills.

Of course! There I took my first steps out of the sandbox and learned how to set up my own Python environment.  I went over the basics again, learned a bit more through teaching, and hacked a few projects.  It was like any other gathering of women learning a skill, except for instead of the usual pot luck that women always obligate themselves to, there was that free take out again.  I went to a follow up meeting a few weeks later.  More free beer and food, the origins of which were not entirely clear to me yet.  But they soon would be.

Montreal, it turns out, had been chosen to host PyCon, the North American conference of all things and people Python, not just for 2014 , but 2015 as well.  At the last PyCon there had been some controversy over a sexist remark, so Python HQs decision to buy a lot of Montreal women free dinner whenever they got together to learn Python, seemed a wise one.  They were interested in kids too.  Apparently at the last PyCon, everyone had walked away with a free Raspberry Pis.

So here I now am, a little over eighteen months since I signed up for Code Year, taking some time to reflect.

Since January,  I’ve pulled back from my blog to get  focussed on the history and theory behind these skills. With research, I have a better sense of the bigger picture.  I’m working my way through those codecademy lessons again with a slightly more sophisticated eye than I had back when I was half parroting my way through. I’m working at writing the kind of book I wish I’d had when I started.  Something that would inspire newbies to keep at it, and help them better understand their place in the master narrative of computer science.  Something that doesn’t get too tangled up trying to explain the things that they might not be ready to learn yet, but that glimmers with enough light to help them blunder their own way through. Something guided, I hope, by the proverbial finger that directs us to the moon.

I’m reading Tim Berner-Lee’s memoir and just learned that his mother Mary Woods was one of the programmers on the Ferranti Mark 1, the first commercial computer in England. Back then, as in the U.S., women made up roughly fifty percent of programmers.  His parents met at a Christmas party about a year into the project.

Some of those early programmers learned to code because they had a specific job to do. And usually that was the best way. But not everyone learns like this.  According to Grace Hopper, inventor of the first compiler, it took her two years to get her male peers to even look what she had created. They were so enamored with the snippets of code they were playing with. True, none of them can take credit for the compiler, but obviously it led them to other stuff.  I’m not against projects based learning. But I put a year aside to learn to code for code’s sake and doing so has  led to me places and projects I had no idea even existed eighteen months ago.

Fortunately, I have little shame about my newbie perspective. Maybe one day I’ll learn to worry more about all the time I “waste” learning.  I have no idea what I’m going to have experienced or learned eighteen months from now. But if it’s only half as interesting and fun as everything I’ve learned in the last eighteen months, I’ll still consider myself on the right track.

Advertisement

5 things I learned about MOOCs in 2012

About  a month ago, The New York Times declared 2012 the year of the MOOC. That’s Massive Open Online Course, in case you haven’t come across the term yet.

Given how much time I spent enrolled in MOOCs this year, I kind of knew this already. But for those now dipping their toes into this phenomenon, here are the top 5 things I learned this year.

1.  MOOCs are addictive. Like seriously addictive.  You think the internet is distracting now.  Wait until you’re juggling the demands of the five fascinating  Ivy League courses you signed up with through Coursera.  I’m kidding, but not entirely. Somewhere around July I found myself wrestling between my Code Year resolution with Codecademy and my determination to complete the Studio Track of Stanford’s Human Computer Interaction course. What began as a five week project soon stretched into something closer to eight weeks as Stanford realized how unprepared most people were for the work involved in field researching, building, testing and peer reviewing a web app.  I did it.  But by September I was burnt out.  Had I not dropped out of Machine Learning after half a video and made a firm decision to bear down, I never would have grocked Python (or learned the word “grock”).  So if MOOCs are something that might interest you in 2013, make a resolution now not to become a MOOC slut.

2. MOOCs are an awesome way to meet people in your home town. This is especially true if you live in a tech oriented city. If there isn’t already a meet up somewhere in your town in the subject you’ve become interested in you can probably start one. Or you can start meetups specifically around the course you happen to have enrolled in. Those meet ups will no doubt lead to other meetups. After organizing the first Code Year meet up in Montreal, I met and introduced people who went on to put on the first Montreal Maker Faire. The interests I cultivated through that venture led me to  WordCamp Montreal, Semantic Web meet ups,  MTL Girl Geeks, MTL Girl Hackers, to mention only a few groups I discovered over the year. Problem was I was so over enrolled in MOOCs, I often couldn’t go to all the things I wanted to.

3. MOOCS are like running.  They’re free. They require little expense or equipment. They’re outside the usual  parameters of civilized life. You make your own challenges. You feel your strength, endurance, and confidence build. You’ll want to quit right before you reach the finish line/personal goal/personal best.  But if you bear down, you’ll learn the effort is really worth it.

4. MOOCS are like a treadmill. They can be a great stepping stone to real life learning. If you’re shy of university life for whatever reason, or you want to try out a subject first to see if it’s for you, MOOCs are great.  But at a certain point you need to find an entry point into the complexities of real life learning.  That might be a meet up, a project independent of what you’re learning in the MOOC, or, in the end, a classroom course in that subject. If MOOCs are your only source of learning you’re going to get bored.

5. MOOCs are especially great for women. At one point this year, I came across a popular  tech ed blog, where it was speculated that the gender ratio of MOOCS were probably not much different from those in regular Computer Science courses. i.e dismally biased towards men.  I’m not convinced that’s true. Almost all the people who showed up to my Montreal Code Year meet ups were women. My experience of peer review in the Coursera HCI course is that there were many women in the course. And, while I don’t know the numbers, I feel safe speculating that MOOCs will be a significant factor  in restoring gender balance to computer science. (Yes I did use the word RESTORE.)

MOOCS in my experience are a great gateway to equity. This isn’t to say that societies should abandon a commitment to traditional learning.  We’re all going to have to be careful to make sure that MOOCs enable low cost high quality learning, not undermine it.

But I’m from Montreal.  Here we march in the streets and bang kitchenware to keep university tuition fees low.  As a result one out of two  Montreal university graduates are first generation (i.e. the first person in their family to go beyond highschool), by far the highest ratio in North America.

The MOOC can be an excellent learning path, and can do much to fill the equity gap, but it will never be a substitute for a deep social commitment to affordable higher learning.

Snake Eyes

Image

Python is killing me.

My enthusiasm of two months ago is drying up and all the things I thought I was going to love about Python, I now hate.  I miss JavaScript. The comforting closure of the semi-colons. Those curly brackets were always more fun than I gave them credit for. They told you where things went. They provided structure, style and whimsy.

Python is all empty space. And while the basic logic is still there, why do all computer languages have to do things differently?

Mostly, I guess I just resent that it’s hard. Which is probably a life problem, not a Python problem. Why do we always think that life is going to get easier?  I’ve been baby stepping my way through, but I’m falling behind.  I was on track to finish Code Year on time, and every week my percentage of completion is getting a tiny bit lower. I feel like a marathon runner who’s fading in the last mile.

Must. Get. The. Passion. Back.

Yesterday I was thinking about the programming satori experience that got this blog rolling. I remember how I felt after I got through the Snake Eyes  challenge. The world took on this complex, computational beauty that I never  would  have seen If I’d given up . For the week after that challenge I was thinking in code. I felt enlightened, stronger.

I’m sure Python has something to teach me too. I just have to be willing to re-commit and set a challenge to make up the ground I’ve lost.

One of the advantages of being the mother of a twelve year old is that I have many inspirational Hollywood movies to choose from in this mission. A scene from  the Karate Kid remake comes to mind. The one where they visit the Taoist monastery and Jaden Smith learns that the snake is not controlling the nun. By copying its movements the nun is controlling the snake!

There is some profound metaphor in there that I don’t quite understand yet. But I will find some way to make that allegory work.

Because if I’ve learned one thing from a year of learning to program, it’s that it’s usually right at the point when nothing makes any sense that the magic is about to happen.

Hello Python!

This week at Codecademy we started Python.

Not that I resent the eight months that I’ve spent mastering the fundamentals of JavaScript, HTML/CSS and JQuery, I’m sure it’ll come in handy some day. But if I’d known about Python, this is where I would have started.  And something is telling me that this may be where I’m going to stay.

First off, where is the crazy making syntax!  Oh, those first weeks of JS, where every rule  was such an affront to my sensibilities as a writer.  Semi-colon over use.  Periods in the middle words. Capitalization of second words.  In the early days,  my brain rejected JS like it was a kidney of the wrong blood type.

Python is made for writers and I’m guessing much better made for families. It’s also made for people with a sense of humour. The name of the language comes from Monty Python, which makes it particularly appropriate for my family. My mother went to Oxford, and was once in a skit with Peter Cook and Dudley Moore. Bragging over. She played the American girl with a nice rack. Still,  British comedy was pretty much a side dish at dinner where I grew up.

Python tutorials are known for their cultish flourishes, and use “spam” and ” eggs” as introductory variables.  Over at Skillcrush, (an exceptional ed tech startup directed particularly at  women),  I recently learned that Python is used for  sites like Youtube, reddit, and Yelp.

I can’t tell you much more about the language, since I only started learning it yesterday. But in keeping with our theme of comic relief, here’s the funniest thing I’ve seen this week. Yelp reviews read by actors.  Just an example of the joy that Python is bringing to the world:

Codecademy scores 10 million and Familycoding gets a nice shout out…

So six months ago Ben and I signed up for Code Year, with Michael Bloomberg and about 400,000 people.  We didn’t even really know what coding was.  Codecademy was just five month old puppy of a Start-up.

And look at us now.   Here’s Codecademy announcing $10 million in their second round of venture funding (a big chunk of that from Richard Branson).  But notice who’s mentioned in the list of accomplished students.  Yes that’s us,  Juliet Waters and her son Ben.

I haven’t been blogging as much lately because I’m deep into Human Computer Interaction, a free five week online course given by Stanford through Coursera, another high quality free education startup.   There I’m designing my first web/app and getting rigorously vetted by my online peers.  But I’m still keeping up with my Code Year.  More than ever, I’m going to need all that JavaScript to get it functional.

If that weren’t keeping me busy enough, last night I went to a first meeting of organizers of  Montreal’s inaugural  Mini Maker Faire, which will be at the Olympic Stadium August 25-26.

One day soon, I will come up for air and do a nice long blog post.

In the meantime here’s MythBuster’s Adam Savage talking about the importance of taking risks….

The Women


Rear Admiral Grace Hopper, surrounded by her team of programmers

One winter Augusta Ada Byron King, Countess of Lovelace, became obsessed with a puzzle that had become popular in the circles of Victorian aristocracy. Peg Solitaire starts with thirty-two pegs arranged on a board in the shape of a cross around a central, empty space. The goal is to jump over adjacent pegs, which are then removed, until only one peg remains.

Ada Lovelace was the only legitimate child of Lord Byron, the rock star poet of the Romantic Movement. A bitter divorce meant that Ada never met her father.  As an eccentric antidote to what her mother, Annabella Millbank, baroness Wentworth, perceived as an insanity rooted in a talent for poetry, it was arranged that Ada be tutored from an early age by some of the era’s great mathematicians and scientists.

At the age of seventeen, she met Charles Babbage, creator of  the first computer prototype. From the questions she asked about his “Thinking Machine,” Babbage could tell Ada was a better mathematician than most of the university graduates he knew. They developed a collaborative correspondence that would last the rest of their lives.

Ada’s winter of peg solitaire produced an inspiration and she wrote to Babbage: “I have done it by trying & observation & can now do it at any time, but I want to know if the problem admits of being put into a mathematical Formula, & solved in this manner …. There must be a definite principle, a compound I imagine of numerical & geometrical properties, on which the solution depends, & which can be put into symbolic language.”

From that point on she put her talent and education towards understanding this symbolic language, and wrote what is now regarded in the history of computer science as the first recursive algorithm.

“The Analytical Engine does not occupy common ground with mere “calculating machines.” It holds a position wholly its own. . . A new, a vast, and a powerful language is developed . . . in which to wield its truths so that these may become of more speedy and accurate practical application for the purposes of mankind than the means hitherto in our possession have rendered possible. Thus not only the mental and the material, but the theoretical and the practical in the mathematical world, are brought into more intimate and effective connexion with each other…We may say most aptly, that the Analytical Engine weaves algebraical patterns just as the Jacquard-loom weaves flowers and leaves.”

This is why if you take Stanford’s online course Introduction To Computer Science: Programming Methodology you will learn from its charismatic professor Mehran Sahami that Ada Byron is considered the first computer programmer. If you signed up last week for Stanford’s five week Human Computer Interaction studio course, offered free through Coursera, you would have learned from associate professor Scott Klemmer about Rear Admiral Grace Hopper, the inventor of the first compiler.  Hopper  is not only credited with the word “debugging”, after a moth was discovered in the lab, she conceptualized machine independent languages and oversaw the team that invented COBOL.

If you don’t have time to take a free Stanford course, at least read this digest of Stanford talk by CS historian Nathan Ensmenger. Talking about his book The Computer Boys Take Over: Computer Programmers and the Politics of Technical Expertise, Ensmenger explained how the world of computer programming was once so dominated by women, that it was stereotyped as a female profession. In the early 1940s the University of Pennsylvania hired six women to work its ENIAC machine, generally considered one of the first computers. The “ENIAC girls” are considered the first computer programmers in the U.S.   When Cosmopolitan interviewed Hopper in 1967, she explained why it was such a particularly good career choice. Programming she explained was “just like planning a dinner. You have to plan ahead and schedule everything so that it’s ready when you need it…. Women are ‘naturals’ at computer programming.”

What happened? A job shortage in the 60s resulted in the equivalent of an affirmative action program to make the profession more appealing to men. Newly created professional associations actively discouraged the hiring of women. Computer industry campaigns linked women to error. Programming aptitude tests, the results of which were widely available in fraternities and Elks lodges, were introduced to further advance the prospects of men and set barriers up for women. The ongoing job shortage, however, meant that women continued to be hired. By 1985, women still represented 37% of computer science graduates. That was the year that Radia Perlman invented the spanning-tree (STP) protocol. Because STP is so fundamental to building computer network bridges, Perlman has been called “The Mother Of The Internet.”

Currently women represent 18% of computer science graduates in the United States.

I knew none of this when I signed up for Codecademy’s Code Year challenge, in January. But by June 2, when the New York Times ran an article on a highly publicized sexual harassment case in Silicon Valley, I knew enough to balk at the lede: “MEN invented the Internet. And not just any men. Men with pocket protectors. Men who idolized Mr. Spock and cried when Steve Jobs died. Nerds. Geeks. Give them their due. Without men, we would never know what our friends were doing five minutes ago.”

Fortunately, at least one other woman did more than balk:
“What a steaming turd of an opening line in David Streitfeld’s otherwise serviceable New York Times piece about the Ellen Pao/Kleiner Perkins sexual harassment lawsuit, and gender discrimination in Silicon Valley” Xeni Jardin blogged in Boing, Boing. When she tweeted her post she was s greeted with enough Hell, yeah’s that her  storification of Twitter responses reads like an instant oral history.  A history written not only by women, but by men who had learned programming from their mothers and who proudly traced their programming lineage back to grandmothers who were pioneers in the profession.

Much, perhaps too much is made, about the need to find ways to “attract” women into the field of computer science. How about we re-frame this as a restoration of the place of women in computer science?

Let’s go a step further. Let’s restore it as a place that is welcoming to the average citizen. Nothing against geeks, I consider myself one, and have no shame about that. But it’s time for computer science to stop pretending this is a skill that can only be learned by boy geniuses.

There will always be a place for boy geniuses, and a need for programmers both men and women with advanced math skills. But more natural, user friendly languages and tools are being invented every year to make basic programming skills more accessible to children and adults of any age: from MIT’s ingenious Scratch to last week’s release of Blockly, Google’s first visual programming language.

The time has come for everyone to occupy the world of information science. It doesn’t matter whether people choose that world as a career, a leisure time obsession, for one month, one year, one winter, or hopefully, this summer. It doesn’t matter whether people start it at Stanford, Codecademy, or Code Hero (a role playing video game that aims to teach code literacy under the mentorship of Babbage, Lovelace and Alan Turing.) It doesn’t matter when or why we learn to code. What matters is that a critical mass of people start somewhere so that we can reverse, or at least buffer, a growing trend towards techno-elitism.

To use the three important words that have been used by mother coders since the dawn of time, before the invention of computers, and if all goes well, for millennia to come.

Just try it.

Things Being More Equal Than Others

It will soon be six months since I started my Code Year pledge with codecademy.com. I’m still going strong. I’ve even started beta testing a few courses ahead of time.  But this doesn’t mean that learning to program has been easy.

All my new learning is at the fresh cement stage. If I don’t take stock while I can still see the rocky road behind me, I become useless to the people still on it. So, I’ve decided this would be a good time to write about one of my biggest stumbling blocks coming out of the gate.

It was that damn = sign, and the subtle, but really important ways that this sign is different in imperative programming than it is in arithmetic and algebra.

For those of us who never continued with math beyond high school,  = has a pretty rigid meaning. It means “the same as”.  Things on each side of it evaluate as the same.  Sure, we understand that the value of a variable can change.  If  x = y + 1 in one algebra exercise,  we accept  x = 2y + 1 in the next one.  But essentially, what isn’t supposed to change is that both things on each side of that symbol have the same value.

In JavaScript, however,  = means something more like “attached to”.  Or “associated with” or “same type” or “contains all of these things” or is the same as “for a limited time only!”,  depending on the context in which it is being used.

Much of  coding is  building quickie archives of associations, archives that can just as quickly be dismantled. So programming needs an equal sign to have a much broader, less sticky meaning than it does in math.  In math the equal sign is like glue.  In programming it’s more like a post-it note.

For instance  x = 0 used in a programming algorithm usually does not really mean x is equal to 0.  It’s a way of saying that x is a number and  it will be starting at 0. So if we put x in a standard programming loop like (x = 0; x < 10; x++)  it means that x’s value is going to increase in numerical value by one, each of the 10  times we run that loop.

If we write x = ”  ” then  what we’re saying is that x is a string, i.e. some kind of phrase,  which usually means x will be used as a container for whatever words or sentences we want to plug into x.

If we want to make x stand for a particular series of actions,  we turn it into a function by writing  x = function (). That series of actions will be repeated every time we write x().

X can also be an array, a list of things, as in x = [1, train, $, 104, poodle].

In programming if you want to convey that something is actually equal  in the way normal people understand equal, you add an extra =, or just to be safe two extra equal signs, x === y.  This gives x what is called a “Boolean” value, i.e.  the variable either is or isn’t exactly this thing. For example:

 if (x === 3) {do this thing};

in this case  x has to be 3  for the action in  between the curly brackets to be executed.

if  (x !==3){do this thing};

means  do this thing only if x isn’t 3.

Write:  if (x=3) {do this thing},  and the computer will spaz out because your definition of  x is too vague, so it doesn’t know what to do.

****

If you learn to program with a bright sixth grader, as I did,  you may find that they grasp this floaty = concept much faster than you do.

Sixth graders don’t have to unlearn the = sign because they’ve just started learning algebra. Their brain has just freshly opened to the fact that an equal sign can be used in more interesting ways than previously known.

If your sixth grader is anything like my sixth grader, he or she  may very well kick your ass in the first twenty hours  of programming, as you stumble again and again  over whether that variable is the “same as “ or “sort of like” something, and hurt your brain further,  trying to figure out why it’s attached to that meaning in one place of the algorithm, but not in another place.

Even when I understood the difference theoretically, my brain kept reading the sign badly again and again. It was like that Stroop Test,  where someone shows you the word BLUE written in green ink.  When they ask you the color of the ink,  you keep saying blue because your brain prioritizes the language definition over the visual.  My brain was clamped on equal being equal, even when I knew it wasn’t.

“But wait!”, you and an unfortunate number of other educators might say.  “If we expose children too early to the more complex and nuanced programming concept of = won’t they get all confused when they learn algebra?  Don’t they need a period of time when the = sign has a more limited scope?”

You may even develop this idea further.  “What if after being exposed to all this = sign confusion, some children end up learning algebra [cue music to soundtrack from Psycho] at a slower rate. What horrible things will this do to their self esteem?  Maybe they’ll give up and refuse to learn algebra all together, in total frustration!”

This is the argument used by those  who think only really, demonstrably super smart kids should be exposed to programming in middle school.  Ideally in expensive summer coding camps reserved just for them.  And this is probably the argument that will solidify the growing gap between the technologically literate, and the now merely language literate, for much longer than it should exist.

It’s also the argument that will keep girls from mastering code as a matter of course, since they don’t tend to sign up for summer coding camp as frequently as boys, and by the time the girls are given the option of learning programming, they’ve developed a misconception about computer science as something only of interest to social isolates (var nerdyGeek = “social isolate”).

This is the same reasoning people use when they bring up studies that show  children raised in bilingual environments exhibit a significant language delay.  (Trilingual environments, they argue are even worse!)

I can only argue against this from anecdotal experience. But I will argue against it, passionately.

I’m a Montrealer, so my son, Ben, learned English at home, but went to daycare in our French speaking neighborhood.  To make matters “worse”,  I had joint custody with his father, who was born in Israel and spoke to him in Hebrew.

Indeed, this created a significant language delay, to the point where, when he was two, we had his hearing tested just to be sure.

But there was no hearing problem.  And not only was there no hearing problem, by the time Ben hit kindergarten he was reading fluently in both French and English, counting to a 1,000 and already starting to grasp a little multiplication.  Because by then, his brain was a language learning machine.

Ben’s not a genius (he’s been WISC tested. Apparently he’s at the high end of average).  He’s just a smart kid whose brain now codes information a little faster than normal kids because he spent his early years in an information rich environment where there was a lot more meaning to sort out.

If your child maintains a coding practice, even if it does cause a little confusion at first,  it’s a good guess he or she will not be falling behind on the math curve for long.  In fact, before you know it they will probably be three times as equal as the other kids.

Or if you want to contemplate a really scary scenario [Psycho refrain] they will probably become three times as equal as you.

Three Ways Learning to Code Would Make Michael Bloomberg A Better Mayor

Earlier this year, this post was included in Should You Learn To Code, a collection of posts put together by Hyperink Press.

Thanks to Jeff Atwood’s provocative column Please Don’t Learn To Code, the debate about whether or not the average person should learn to code rages on.  The Wall Street Journal weighed in yesterday with this Atwood  quote:

To those who argue programming is an essential skill we should be teaching our children, right up there with reading, writing, and arithmetic: can you explain to me how Michael Bloomberg would be better at his day to day job of leading the largest city in the USA if he woke up one morning as a crack Java coder? It is obvious to me how being a skilled reader, a skilled writer, and at least high school level math are fundamental to performing the job of a politician. Or at any job, for that matter. But understanding variables and functions, pointers and recursion? I can’t see it.

I’m not a crack Java coder, or anywhere close.  But even after five months of programming lessons I feel that I can confidently come up with at least three ways that Michael Bloomberg would become a better mayor without even becoming a crack coder.  In fact, he could remain a crap coder, and probably still come out of the experience as a better mayor.

1. He might learn just enough about programming to start considering all the different kinds of operating systems there are now.  Maybe he starts having daydreams about switching to Linux, and starts thinking about all the ways a thriving metropolis like NYC might save money from switching from Windows to Ubuntu.  Probably he doesn’t, but he instructs a few minions to at least start researching more open source software that the city could use.  Every once in a while he starts nagging his education department to see how they could improve school budgets and efficiency by using open source where appropriate.

2. He finds himself walking into a meeting and without realizing it, thinking about problems in a totally different way. Instead of spending hours debating all kinds of solutions he asks himself and the people around him: “what is the smallest, most significant, repeatable action we could take right now to solve this problem?”  A few months of coding has nudged his brain in a different direction and before he knows it, he’s cutting through hours of wasted time with more creative and efficient solutions.

3. He’s still having those switching to ubuntu fantasies. Oh, he’s too old.  But what the hey, he decides to send every child in NYC a RaspberryPi, the $25 dollar, credit-card sized, Linux computer that has just started shipping out of London.  Instead of wasting hours playing video games some of these kids learn how to make their own damn games. One day a critical mass of those kids grows up to become crack coders and change the world in ways we can hardly imagine.

So there Jeff Atwood.  You asked, I’ve explained it to you.

Now can everyone just get back to their codecademy lessons in peace!

Six Reasons a Non-Computer Nerd Might Want to Learn to Code – Technology – The Atlantic Wire

Six Reasons a Non-Computer Nerd Might Want to Learn to Code – Technology – The Atlantic Wire.

This is something of an analysis of the “everyone should learn to code” meme.  Except that it explores only the reasons why people might want to learn to code, which is not exactly the same as why they should learn.

Don’t get me wrong, I’m not trying to take the fun out of coding by turning into a moral imperative.  And the last thing any parent should do is  turn this into educational equivalent of vegetables.

But if we’re going to list the real advantages, and get into arguments with elite  programmers who keep telling us that newbies are wasting their time, we need something deeper than “it’s useful.”

If you’re a software engineer whose primary source of work is software manufacturing then yeah, there’s not much motivating you to preach to the masses to learn how to make software.  If, however, you’re a more politically minded programmer devoted to creating a more efficient world or let’s say more open source software that might massively reduce government and educational spending, then it’s more than just “useful” to have a citizens who know what you’re talking about.  It’s essential.

Because nothing is going to change until a critical mass of the population understands enough about computer science to pressure their respective government or administrations into making the significant changes that have all kinds of economic and social advantages.

So there.  A reason we should learn to program: because it might inspire others to do the same, and then maybe we’ll have a society that is better able to function as a more participatory democracy.

But don’t tell the kids that just yet.

The Parent Developer

I’ve actually been coding for a long time, without realizing it.

If we remove all the syntax of computer language and look at what the bare bones of coding is, it’s just using logic, reason and simple commands to create repeatable behaviours.

This is what parents do with children.

They start with small instructions,  baby steps and repeated routines,  appropriate to both the child’s abilities and the parent’s still developing skills as a programmer of babies.  Then as the child  starts to develop cognitive abilities, the parent sets up a system of conditionals: acceptable choices the child can make that will not include choices that will  bugger up their lives.

Figuring this out is a frustrating challenge, but it will probably work well enough while the child is still not much more than a new Object in the parent’s mind, something that in theory should inherit  all her workable (and perhaps not as workable as she’d like) methods.

But at a certain point the child hits  the age where he now has the abstraction abilities and the independence  to start programming his own life.  And this is where the real problems start, because the parent is  no longer the programmer with a child Object.  The parent is now dealing with a junior developer.  And if the  parent does not know how to establish her position as senior developer, there will be blood.

That’s why I think this is such a great time for Ben and I to learn how to code.  Because even if no one in the family ever becomes a professional programmer, we’re still regularly working together on solving problems with commands and the kind of simplification skills that  inevitably spill into our lives.  Ideally this will help us solve problems in ways that are more neutral and productive than what usually happens between adults and teenagers.

Obviously Ben will not stay a junior developer in this family for long.  This is the law of life and technology. Coders move on. But for now it’s still my responsibility to instill good thinking, writing, and commanding habits.

It’s all about those transferable skills.