TEACHING RAILS

The Calculations

Over the next four months we met every two weeks and step by step, we were discovering The Awesome World of Ruby et al. The course covered Ruby language, Ruby on Rails, Javascript and some popular tools for RoR applications like Devise, Pundit, Sidekiq or Carriewave.

Every student also had a mentor, who was responsible for motivating students and checking their work inbetween meetings.

The Plan of Attack

As a teacher, I came prepared with 3 years of experience with Ruby on Rails, 10 years of experience with programming in general and some presentations with issues and exercises to do.

Apart from a short course in Linux management I had done before, I didn’t have any experience with teaching. As for the students, I only knew there were going to be ten of them and that they come from very different backgrounds – for some of them it’s their first brush with programming, while others tried to learn C or Ruby on their own before enrolling in the course.

I decided to make two resolutions – I will be patient and I will explain everything if needed (no “we already covered it”). First resolution has stood the test of time, but the second – quite obviously – didn’t. I decided to not do any special preparation regarding the things I was going to teach – I work with Ruby/Rails every day and I’m feeling pretty confident in my skills in that area. At most, I read the presentations I had.

The Challenge

One of the first things that became absolutely clear for me just after the start of the course – you can’t explain everything. It’s a very sad realisation for someone like me, who likes to dig in and discover how things work, but in the limited time of one meeting there is only so much you can teach and that can be remembered by students. Turns out you can be a very decent Ruby programmer without knowing exactly how are Arrays actually represented in memory or how exactly Devise works.

Lessons were taking place on Saturdays and Sundays from 9am to 5pm. It’s important to realise that teaching is pretty exhausting work – apart from explaining the material, you also need to always be ready to answer related (or not so related) questions and solve various problems that your students have.

Coffee is your friend, but the most crucial is the aforementioned patience. For people who have not been coding before, concepts that are obvious for programmers – like loops, types or even variables – need to be learned and it’s not an instant process. If you have been programming for XX years, you consider math easy, can list all known programming paradigms in the middle of a night, it might be hard to place yourself in a shoes of a person who isn’t really sure on which side of equal sign does the name of the variable go. But it’s vital that you do it. Basic concepts like variables, loops or arrays become so natural that it’s hard to comprehend how can somebody not understand them right away, but they are harder than they seem to “us programmers”.

An additional difficulty, especially in the beginning of the course, was explaining those concepts so that they are well understood. In my opinion it’s not possible to learn Rails without learning Ruby – although I know that some would argue it’s not the case. It’s true that Rails have its own patterns and a lot of things can be remembered rather than learned in the beginning. However, I think that in order to become conscient RoR developer, a moderate understanding of Ruby, OOP or SQL is a must. Teaching people to program is quite different than teaching Rails – while with Rails there is a lot you can expect to just be accepted or believed (nobody needs to know how callbacks work in the beginning – only what they can do), programming concepts should be explained in more detail.

Engaging The Force

So, how does one do that?

Patiently.

It probably seems like I’m repeating myself all the time, but I can’t stress enough how important patience is. Even my most motivated students were known to make a syntax error here and there – it’s part of normal learning process and there isn’t really anything to do for a teacher other than to show what the error is and how to fix it. In time, they will learn to fix them on their own, but this will take way more than one or two errors.

Another thing to note is that Ruby is not as easy as it seems. If you started learning Ruby with knowledge of C/Java/Python, everything probably seemed so clean and nice and simple. Try to think about it though, and you’ll notice:

1. What’s with the parentheses? Should I use them? Shouldn’t I?
2. What’s that self thing? Sometimes I have to use it (eg. attr_writer – self.variable = ...), sometimes I don’t (attr_reader – variable) and sometimes I can’t! (private def some_method – self.some_method will throw an error)
3. Blocks. I bet that even some experienced programmers (of different languages) would need a moment more than expected to understand #inject

Apart from simple fixing the errors, there is the issue of actually tranferring your understanding of things to your students. To do this, you will need a lot of flexibility. Some students were satisfied with Array being just an ordered list of elements. Others needed more visual analogy, like a shelf with numbered places on which you can put things. I found myself explaining the same things multiple times in different ways – which is quite challenging exercise!

But, as I said before, you can’t explain everything. When I was explaining relations in Rails, it was more of a “that’s how you do it, and it allows you to do that and that. You want that, it’s awesome”. Fortunately nobody asked me how this works – I don’t think that junior developers need to know about reflections.

Situational Positioning

Due to the format of our course (meetings on every other weekend and long breaks) we had to ensure that periods between those weekends are productive for our students – without them practicing in that time the course would not work at all.

Some of my coworkers agreed to be mentors for students in the course. Mentors’ work was to verify exercises that were assigned during the weekend meetings and help with issues that were arising while completing them. Students were communicating with mentors via Slack.

I was a mentor for two of my students. It was significantly different form of teaching – and full of its own pitfalls. One thing I realised a bit too late is that a good programmer must be independent – they should at least try to solve problems on their own before asking for help. And being available on Slack all the time not only took a lot of my time, but also didn’t inspire such independence.

Don’t get me wrong – a lot of a questions I was asked as a mentor were valid and answering them was expending knowledge of the students. It’s very easy to go into “teacher mode” though – and explaining again all the issues from weekend meetings. From today’s perspective I think a mentor’s role is to overview, supply useful links and ask some questions that might help find the solution. Occasional explaining might happen, but it shouldn’t be a majority of it.

The Use of Intelligence

Every student is different. One of the bigger difficulties was to adjust the pace of the course to fit best for all of the students. Due to the varying backgrounds and general level of ease in accepting new ideas between students it’s almost impossible task.

Our timeframe was 9 meetings – times 2 days times 8 hours gave us 144 hours to go from 0 to Ruby-hero. It was paramount to do whole syllabus in this time – which by itself enforced a pretty quick pace. First three meetings were all about Ruby – then one meeting for SQL, then RoR and one meeting for JS in between.

As a teacher, I always had to know who more or less understands part of the material I was presenting. Sometimes it was enough to ask if this is understood, sometimes I did little tests. For example, I asked all of my students to send me their own definitions of Ruby concepts, like class, self, method, variable etc, on Slack. If some issue was particulary unclear, I would go back and try to explain it again.

Illusion and Reality

To summarize, teaching was an even more difficult endeavor than I thought it to be. It can also be very rewarding. Nonetheless, it’s hard work and it’s effects of it depend not on the teacher alone – the student’s own effort is even more important in their learning. This makes teaching very different than programming, where you usually can own all successes and failures. It’s important to remember this difference.

It also forces you to think about issues you don’t usually think about – explaining things also gives you a better understanding of them. In that way teaching can also make you a better programmer.