Training Ruby devs in Object Oriented Programming Should be Simple.

This long writing is about my experiences with training beginner developers in Ruby and Rails. The ideas should work with other Object Oriented languages, though.

TL;DR: Teach people about building small, simple things. The rest gets much easier after that.

At the time of this writing, I've been training ruby on rails developers for about 3 years, and developing for about 6 years (not that long, I know). Mostly legacy apps, which means my main job is to refactor that scary code you just want to close the file and walk away as fast as you can. We develop new things from scratch every now and then. Management thinks its proactive. We're actually just keeping ourselves sane.

In university, I learned OOP by seeing a Student class inheriting from a Person class inheriting from a LivingBeing class inheriting from a Thing class. Awesome! So, OOP is all about inheritance, right? It makes sense if you consider librarians' Classification and Taxonomy, where I believe object orientation began (should have paid more attention to that class). In fact, Inheritance is part of the Three Pillars of OOP: encapsulation, specialization, and polymorphism (on specialization). Complicated names, right? It gets even more complicated pretty fast.

As soon as you start learning a bit more about OOP and best practices, you get in touch with design patterns. Your class is too big? There's a pattern for that. Your code is getting complex? Hey, you can just use one of these software design patterns to solve your problem: Creational, Abstract, Builder, Factory, Prototype, Singleton, Adapter, Bridge, Composite, Decorator, Facade, Flyweight, Proxy, Chain of Responsibility, Command, Interpreter, Iterator, Mediator, Memento, Observer, State, Strategy, Template and Visitor! That should be quite easy for a beginner, right?

So, on my current company, we hire people straight from the university. We're actually the university's IT, so that makes sense. Most of them are still at their second year or so, with not much experience in programing. The company ( doesn't have that much money, so as soon as people learn a bit on the job, they get better offers elsewhere, and we are given a new batch of fresh developers. And they have to touch production code soon. Which meant our training had to be effective. It's important to understand that effective does not, necessarily, mean fast.

How should we approach training?

Teaching Ruby?
Nope. There are enough good free ruby tutorials online. There's Ruby Koans, Code School, Codecademy. Have the money? There are a lot of great books on it too. The same goes for Rails. We tried giving our own introduction courses, it was an utter failure. Just trust the community.

Instead of focusing on having beginners learn Ruby and Rails on their first few days and having them write production code with us (which obviously would not work so well), we decided to go very slow. We started burning about a month or two (or three) in training. Our first and main topic? Objects.

Picture a classroom. How many objects do you see in that classroom? But OO style, so a student is an object, a teacher is an object. The lesson is an object. Not every object is visible, not every object is a 'thing'. Some can be made up to better organize our thoughts. Leaning best practices is all about organizing our thoughts.

Next up: building small things. We have a very tiny assignment we make people code. The assignment itself doesn't matter. The language shouldn't either, as long as its OO-ish. Just pick something that involves a lot of logic. We have them do the assignment, and then we start asking questions. What if we added this logic? What if we removed that logic? Get them to understand the consequences of coding decisions.

Then we start talking to them about Single Responsibility Principle. Yeah I know, we weren't going to talk about SOLID yet. Sure, call it High Cohesion and Low Coupling, and explain what they are. They should think about that at every method, not just at class level.

Then we refactor their code with them. We make it simple. This is important, people should understand that OOP is all about being simple. Objects should pass messages, explain to them what that really means. Show them how simple it gets when you start asking information from the right objects instead of going procedural. Then we explain to them how they've began understanding a lot about GRASP just from that refactor. But don't focus that much on the jargon, what matters here is that they learn about building small things. Again, High Cohesion and Low Coupling.

Now comes the hardest (but for me, the best) part. We improvise with whatever we feel they need to learn, and reinforce whatever we feel they lack. Training is a very human thing, there is no silver bullet, you have to understand how each individual you're training thinks to be able to optimize their time and yours. From here on, start giving bigger assignments, have them do a ruby and a rails tutorial (but don't abandon them while they're doing it), remake the assignments in ruby, get them to explain their coding decisions so you can feel what they lack.

SOLID will be very simple to understand once you know about single responsibility and small things. MVC? Same. All of the 127365123 patterns? They’re just great ways to solve problems, all using the initial GRASP ideas. Since they already have a good grasp on that (pun intended), they’ll have a much better time learning everything else.

Some people take a month to complete our current training, others, 3 months. We don't mind at all. By experience, people with decent training will produce usable code much faster than without it. The training time will pay off eventually. As a plus, people really enjoy learning and knowing someone is paying close attention to their learning curve. That alone is probably makes us retain developers longer now.

Ok so, I'd really like to know, how do you train people where you work at? What you wish your training was like, but wasn't? Feel free to leave your experiences bellow, or talk to me on twitter about it. I'm sure we can all learn a lot from each other.