Hello there – A postface to the summer

Time flies. It really does.

One of the things I discovered when I first started this blog is that I really enjoy writing, and as much as the writing, the thinking about and reflecting. I haven’t taken the most direct route into coding by any means and so when I first started, I figured it would be a good idea to write down the little things that can help speed up a coder’s learning – partly for you, the reader who may be anywhere in their journey to coding mastery, but also for me, we tend to forget things if we don’t write them down and think about them!

And yet, it’s been a while since my last post simply because I’ve been too busy doing, and haven’t had a chance to come up for air and think, well, what have I learned the last few months? What would I tell past Jeremy to help him learn better.

Over the last few months I have:

1. Done summer school for the first time and the last – I’m in an accelerated program so we’re pretty much in school year round!
2. Completed the “interview courses” at UBC in Algorithms and Computer Systems – i.e. the ones that are meant to provide the foundational theory for answering most interview questions
3. Built a web application for locating bike racks in Vancouver using Google Web Toolkit for a class project
4. Started a four-month internship (a co-op really) at Axiom Zen, a startup in Vancouver downtown
5. Coded a LOT during my internship
6. Convinced myself (again) that I could definitely work as a software engineer (as a decent one too, I think – but then again I’m biased)




Classes, classes, classes…

The first three points in the list above kept me pretty busy all through summer, taking 4 courses at one time is no mean feat. I was super excited to take the courses that everyone said would prepare me really well for interviews for my next co-op and for a full-time job after graduation, but to be honest, I realized that the profs mostly covered the theory in a somewhat abstract way, and it was left to you to connect the dots come interview time. A typical university education some might say, but with the wealth of resources available out there, and if your one and only goal is to get the best software engineering gig as possible, I feel confident enough to say that learning CS theory in a university setting is not strictly necessary by any means. Helpful yes, but meeting up/being mentored by someone who already knows the stuff and thinking about the own problems – which university sometimes gives you little time to do – is more important. When learning about computation systems or algorithms at university, it’s easy to take little diversions into long and complex areas of the field which, while academically interesting, are not things anyone expects you to know in the real world 🙂

Some of the things I learned this summer were definitely interesting though. Particularly the intermediate algorithms course, which covered different approaches one can take to designing an algorithm for a particular problem – everything from stable matching to the debate over P vs NP.



An internship

I finished my last set of exams in late August, took a weekend off (can I even say that? Weekends are default holidays right?) and started my four-month software engineering internship at Axiom Zen. It’s technically a co-op since it’s coordinated through UBC and my university program, but there’s not much difference – I’ll call it an internship from here on in, just because it’s probably a lot clearer to anyone who’s not studied in Canada!

Before starting at Axiom Zen, I’d visited the office and the people a couple of times and really hit it off, so I was pretty much raring to go and started the Monday after classes were over. The company works with clients to develop web and mobile apps as well as incubates its own in-house startups, so it’s definitely a very interesting environment to work in. There is a pretty much flat hierarchy, so that’s definitely been a change from my last job where it was very clear who answered to whom and when (not the why so much, they always left that part out).

Learning and working/coding in the real world is a new stage to my coding journey, and one that I’m looking forward to sharing with you over the next few months. The plan is to write short posts with the little nuggets of wisdom that I’ve gleaned from working at the coalface of the industry, things you don’t or can’t generally pick up at school or working as an independent.

Since I started at Axiom Zen, I’ve been treated pretty much like a full-time software engineer and have written lots of code, and just generally gotten involved! That’s definitely something special – we’ve all heard of those internships where you do little more than fetch coffee and sneakily check facebook – so I’m having a good time and learning lots which I hope to translate into a collection of posts. Stay tuned!

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.

What programming language should I learn first?

Now that’s a question and a half.

When you’re a complete novice to an entire discipline, it can be daunting to even know where to begin. Picture this, it’s the new year and you’ve set yourself a resolution to learn how to code. Maybe you want to build a website or a mobile application this year, maybe you think it’ll be a way for you to quit your job and work from home, or make millions by executing your start-up idea. So you get your laptop warmed up, find a comfortable spot and wonder.. where to begin?

Having made a couple of failed attempts in the past and then finally succeeding last summer, here are my three pieces of advice when choosing a first programming language.

1. Programming languages are just tools, more important is the instructional materials available

Ever wonder why people who speak multiple languages can pick up new ones so easily? Being a good coder is a skill and the languages you use are just your tools. At the very heart of it, most programming languages are the same – there are only so many ways you can have an if-else conditional (if you don’t know that means, that’s ok! See point 3). So when you first learn to code, your focus should be on learning a new way to think about problems and a new way of expressing yourself.

You don’t even think about it now, but as a child you would have internalized how to use language to express yourself. You’re going to need to be able to do that so that a computer (and not a human), can understand what you mean.

Rather than worry about precisely what language is “best” for a first time programmer, concentrate on getting access to instructional materials that work for you. Finding that 600 page tome of a C++ book too dense after just two pages? Use it as a doorstop and try watching and following along with videos on sites such as  Udacity or Coursera. Prefer an intense, bootcamp style approach to learning, so that you can be sure of a deliverable at the end? Go with a hacker bootcamp like Dev Bootcamp (USA) or Makers Academy (UK).

With the right mode of instruction (whatever that might be for your personal learning style), I honestly believe that anyone can learn to code.

2. Some languages are more accessible to beginners

When you’re first starting to program, there are going to be lots of things to learn! What you’ll want to do is to take an incremental approach. However, some languages are less forgiving than others and require you to have grasped certain concepts up front. For example, strongly-typed languages like Java, require you to explicitly declare the data type of a variable (String, Integer, etc), while weakly-typed languages like Ruby don’t.

3. Choose the path of least resistance to your goals

This one might be obvious but if you have a particular programming goal in mind, you’ll want to make sure that the language is going to help you achieve it. Here’s an extremely brief overview of the typical areas that first-time coders are interested in and the associated languages

Web Development (the language with the relevant web framework in brackets)

• Ruby (Ruby on Rails)
• Python (Django)

Mobile App Development

• Java (Android)
• Objective-C (iOS)

Games

• C++