The Next Big Thing

Over the weekend, I volunteered as a teaching assistant (TA) at an event for kids who wanted to learn how to code. The two day event was organized by The Next Big Thing, a non profit organization in Canada aimed at facilitating and encouraging youth entrepreneurship, with the first day focusing on basic HTML and CSS skills and the second day on Ruby (the days were lecture-follow-along style). I can’t think of a better way to get kids excited about entrepreneurship than by exposing them to the greatest enabler of them all – technology. It’s crazy to live in a world where a team of 50 or so individuals can produce a messaging product called WhatsApp that is so valuable that Facebook pays 19 billion dollars for it. Technology acts as an exponential multiplier and the sooner young people realize that and exploit it, the better.

The event was well attended and there were about 80-100 people on each day with about 500 or so on the waitlist for the two days. It was hosted at Vancouver’s one of Vancouver’s startups that made it big, Hootsuite, which helps companies manage their social media. I decided to help out at the event as a way of giving back some of the fun I’ve enjoyed while learning to code, and also because I was interested in seeing what the current state of affairs is in high schools in Canada.

Here are a couple of things I noticed this weekend:

1) The kids are getting younger

I mean seriously young. The event was advertised as being targeted at grade 10 to 12 students, about 16-18 year olds, and yet there were two or three 11 year olds each day at the event and lots more 12-15 year olds. A couple of kids had parents on hand to support them at the event, others just got on with it. And wow. They were following along just as well as the other, older students.

Do you ever get asked by older relatives how you use technology so easily and efficiently? My theory, backed up by what I saw this weekend, is that exposure is the key. The more you assimilate technology into your life, the easier to becomes to use it and apply it.

Kids these days are growing up with iPhones and tablets and what have you, so much so that there is little to no barrier to them learning how to code. They really just need to be pointed in the right direction and motivated. And that brings me to my next observation…

 

2) Kids know that there are educational resources out there and can use them

Day 1 started off pretty slow to ease people into the ideas behind HTML and CSS, and as always, there were a few kids who were ahead of the class and for which it was all old hat. And so they were going on CodeAcademy to find out more, playing around with those interactive examples and just getting on with getting on.

There were also kids where once they learned something, were quickly googling information to find out more and then going farther than what had been taught in class. Some of these kids had the foundations of the important life-long CS and entrepreneurial skill of being able to just “run with it”. And by that I mean they were able to learn a little bit of information, get pointed in the right direction, and then start learning a bit more and applying it in different ways. Kids these days no longer wait to be told what to do, they are resourceful.

 

3) Kids don’t ask for help

And a corollary of my last point about kids being resourceful, is that they don’t, and are generally unwilling, to ask for help. There were lots of TAs during the event and rather than hassling students every few minutes by asking them if everything was ok, were generally waiting to see a raised hand and then going over to help that person. Well, there weren’t many raised hands. Kids just wanted to google it themselves and try and figure out the problem, and failing that, just gave up.

And that was extremely interesting. I think letting kids try and solve problems on their own is the number one life skill that we should be trying to teach them (if it can be taught, perhaps just facilitated). And yet, there’s a fine line between leaving them to grow and learn on their own, and making sure they don’t just give up and quite altogether. I think the downside of being able to Google everything is that if you can’t find the information on the first page of Google after two or three searches, you give up. So there’s definitely a need, when teaching kids how to code, to be prepared to step in and challenge them and ask, is everything ok, followed by, can you show me your work?

 

4) Some kids just don’t care

There I said it. There were a couple of high school kids who were essentially falling asleep at the event. Not too many but still a couple. Some of the TAs engaged with them and asked them what their experience was and how they heard about the event, and their response was “my mum made me come” or some variation of that. And I think that’s pretty interesting too. Because on one hand you have this waiting list FILLED with tons of kids who want a shot at learning to code, so lots of pent up demand, and also some kids who just aren’t interested.

And I don’t blame that particularly sleepy kid, not at all. I think the fact his mother recognized that technology is an important part of our lives and that learning to code is quickly becoming a life skill is excellent, but we need to recognize that convincing parents alone that learning to code is a good idea is not enough – we still need to get the kids themselves to buy into it, especially while coding is not a part of the mainstream syllabus (i.e. we can’t force it on them – and arguably, a good teacher should be able to avoid this situation in any event).

In fact, what got me thinking about how the event could be improved in the future is by making sure everyone buys in to the point of the event in the first place. We started both days with descriptions of the technologies and syntax, and a humongous slide deck, whereas, what I think would really have helped, is to show the finished product first and then work backwards to build it. In other words, show what the point of it all is, get them excited, and then both of you are on the same page and working towards the same goal.

 

5) Kids do not have a long attention span

Each day of the event lasted 5+ hours including the lunch break. And that’s a long time. Short quick bursts with interspersed breaks are just better for learning. Enough said.

 

6) Rewind please

Kids respond to resources which they can access and engage with at will. There was often a cacophony of noise during the lecture, and that makes it hard for the kids to follow a long and is arguably not the best use of instructor time. Give the kids as much rope as possible to run with on their own, and help them out once they’ve identified stumbling blocks, i.e. take a flipped classroom approach. This is becoming really popular at contemporary universities in North America, and basically leaves the learning up the core, fundamental material up to the students, with the harder material and tricky applications being dealt with in class.

 

7) Kids need to learn how to code and think like a coder

The first day covered HTML and CSS, and was much better attended than the second day involving Ruby, and I suspect that’s because kids are put off by the idea of learning “hardcore” coding whereas HTML and CSS if you can even call that coding, is much more palatable.

There were lots of kids who were familiar with HTML and CSS but significantly fewer who knew what an if/else conditional structure was.

And so TAing the second, Ruby focused day was much more taxing than the first. And that’s a good thing. I got the feeling I was really helping kids learn how to think in a new way – how to approach problems in a systematic and logical way. It definitely takes a little getting used to before you’re cracking out the FizzBuzz exercise without a sweat.

So it’s kind of funny because the second day when we were teaching the fundamental ideas behind programming and coding, was really when we wanted a full house. HTML and CSS is mostly memorization and syntax and is easy enough to pick up on your own, but coding is something that we really want to be removing the barriers to entry to. There is just no exposure whatsoever to it in most schools.

I think there’s a strong need to emphasize in future events that you do not need to be a hardcore coder or even know anything about programming to attend events like these, and that such events should be focused on actual coding rather than syntactical and markup languages like HTML which students may have encountered before, e.g. in an IT or computer studies class.

 

In short,

the event was a great learning experience. I learned a lot about how to organize an educational coding event in the future – I’d definitely like to run one soon – what to do and not to do, and most importantly, that the current state of affairs in high school technology education is poor to say the least. We need to start addressing it head on by bringing coding and more so learning to code into the public eye. These articles about dropouts founding billion dollar tech companies, while inspiring from an entrepreneurial perspective, leave the “how” of they got there through coding as something ethereal and unknown. Coding isn’t any harder than math, and people/parents/kids/educators need to know it.

Competitions and Code Jams

Given the dearth of posts lately, I’ll be the first to admit that keeping up a blog is hard – who knew that going back to school would be so busy? With midterms and finals happening pretty often, it’s taken some getting used to going from coding (and blogging) everyday to, well not.

Don’t get me wrong, you can learn to be a better coder and computer scientist without writing lots of code (I’m taking an intro to probability class for example), but there’s no substitute for it. You don’t become a better runner without actually having your shoes hit the pavement. So one of the ways I’ve tried to make sure I code often enough is to place myself in code heavy situations: coding competitions that are held on campus, entering Google Code Jam, and also doing hackathons. Here’s what I’ve learned:

1. Microsoft Coding Challenge

A few weeks ago, Microsoft came by UBC and hosted a coding competition for an evening. If you’ve never done one of these before, it’s a great experience. If nothing else, it gives you an idea of where you stand relative to other people. The format that evening was to break up into groups of three and you were then give a couple of hours and 6 problems to solve. Along with the problems, some small sample input and expected output of your solution was provided. Once time was called, you were then given 10 minutes to run large inputs using your solution code, the output of which was sent to the judge. The team that solved the most problems in the given time won cash prizes. Who doesn’t love money and the bragging rights that go along with a win?

The types of problems we had on the night varied in difficulty. The hardest one (at least if you hadn’t done it before) was writing a Sudoku solver (I doubt many people could have done this in the given time frame without having seen a solution beforehand), while the easier problems were similar in difficulty to this one from Google Code Jam where you’re given some money and the price of some items in the store, and have to find the position of the two items that will match the money you have.

My team ended up doing ok, I think I may have cost us third place with my “accidental” edit of the large input before running it through my solution (don’t do that), but it was a great experience. I learned pretty quick that my coding skills weren’t as rusty as I thought, but also that there was still quite a lot I could do to improve my placing next time around.

2. Improving your placing in a coding competition

My top tips for doing well in a coding competition:

1. READ and understand the problem description before even thinking about writing any code
2. It can be useful to check your understanding of the problem by manually processing (i.e. doing by hand) a sample input or two, to make sure that what you think you should be getting, is what the judges want to see!
3. NEVER edit the large input or output. TRUST your code! One of the problems I did involved text processing and while the sample input gave me something readable, the large/test input did not. I panicked, thought I’d done something wrong, and proceeded to edit parts of the large input thinking a whitespace character had killed my program. I was wrong. My program worked just fine. Gibberish was the solution! If your code works with the sample input, it will almost certainly work with the large input! DOH!
4. Use a high level language like Ruby or Python. You don’t want to have to worry about static typing when you’re up against the clock. The only condition to this is that if your solution is being tested against very large datasets, then a lower level language can be a lot more efficient
5. Make sure you’re comfortable reading and writing to files. This is how you’re going to be processing input and returning output
6. Make use of pre-written snippets of code/libraries (if allowed). Output formats for a given coding competition don’t really change from year to year and you can save valuable time by having the code which goes “Case #1: <output>” written beforehand

3. Hang on a second, how good exactly do you need to be to enter a coding competition?

To enter a coding competition, not much since entry to the qualifying round of coding competitions is mostly free and without requirement. I’d definitely encourage you to enter, no matter where you are on the coding spectrum (just make sure you’re googling and stack overflow-ing ability is up to scratch!) –  you can learn a whole lot just by entering and participating in a competition. If you solve a problem, that’ll build up your confidence and you’ll be even faster next time. If you don’t and you struggle, that’s ok too. You’re going to learn what does and doesn’t work. In Google’s main coding competition, Google Code Jam (which is open to the public – albeit registration has closed this year), you can view any user’s submissions. That means a chance to learn from the best. Reading efficient code that gets the job done (especially when you haven’t quite been able to), is a great learning tool.

Most coding competitions that are open to the public have qualification rounds which aren’t too bad so definitely check those out. Google Code Jam’s problems in the qualification round (at least the first few) are manageable as long as you know how to read to and write from a file, how to write loops.

4. Forget entering, I want to win! How good do I need to be to win competition X?

I’m no expert, having a entered a grand total of two competitions but I’d say that the best coders who win competitions like Google Code Jam (where there’s $15k as the grand prize) are good. More than good, they are practiced. Since there are only so many ways to ask coding competition questions, it becomes a case of knowing certain approaches and algorithms, and being able to apply them to slightly novel situations in the minimum amount of time. For sure, the best guys and girls out there are practicing on sites like topcoder and I wouldn’t be surprised if a lot of them have put in thousands of hours of practice to get where they are.

Most of all, I think they enjoy it. As helpful as coding competitions are for helping you get noticed in the job hunt, you don’t have to place in a competition to land a job at Google or Microsoft. It helps but it’s not a requirement. After all, coding competitions test a very particular subset of skills. Most importantly, the limited time frame of a competition is not conducive to stylistically good and well designed code – vital where the cost of maintaining the codebase for a feature far outstrips the cost of its initial creation.