Coding’s hard; learning to code is really hard.
Yesterday I held my first class at carwow teaching my colleagues from all over the business how to code. There are many reasons for learning to code: being able to talk to developers effectively, hiring developers, building your own program to make you more efficient in your current job or just for fun… The reasons are endless but one thing that’s for certain is the barrier for a beginner is high. Really high.
The first thing I taught in the hour-long session was getting your project set up: creating a directory and files inside using the terminal for our FizzBuzz project, `mkdir fizzbuzz`, `cd fizzbuzz`, `mkdir lib spec`, `touch spec/fizzbuzz_spec.rb`. Not a line of code was written and already we’re running 3 new programs from the terminal.
We already had Ruby installed as we were using cloud 9 for our development environment but it was a clean version of Ruby with no gems installed.
Now we had to start installing gems. As a developer you take for granted all the packages you need and even why you need them; for someone coming to ruby for the first time, using a gem is an alien concept but we installed our first gem anyway. `gem install rspec`. What does gem mean? What is rspec? The questions soon start to pile up and we’re yet to write any code. After 30 minutes of the session the reality was starting to take hold. Coding is hard; learning to code is really hard. You need so much knowledge to begin coding that the coding part takes a back seat initially.
So why did I decide to throw my colleagues into the deep end and get them using Unix commands and TDD? I could have quite easily got them playing in IRB for 30 minutes, iterating over arrays and reversing strings.
The best way to learn to speak a new language is to immerse yourself in it. Put yourself in a position where you’re failing constantly and just about treading water or even drowning (sorry to mix metaphors). The ones who really want to learn to code and keep treading away and asking questions will soon start learning to push themselves forward. TDD is by far the strongest tool in a developer’s belt for pushing yourself forward. When you don’t know where to go but you know what you want to achieve, that’s 90% of the battle. So I firmly believe that as much as I’ve increased the learning curve by introducing TDD the pros far outweigh the cons.
We ended the session with one method written and two tests, which I think is a fair ratio for one hour of coding. I wouldn’t say they understood everything or even half of what I covered but I hope that they can repeat it and pass the knowledge on to others who weren’t able to attend this week. Next week we’ll carry on where we left off.
I aim to run these sessions for as long as there’s interest and if I get one person writing their own program, it would have been worth it.
Interested in making an Impact? Join the carwow-team!
Feeling social? Connect with us on Twitter and LinkedIn :-)
