The Ro Code: Defending Your Code

Dec 19 2017, 10:55 am

Smack dab in the middle of Hawaii and Australia is a tiny Polynesian island called Tuvalu, which currently at risk of submarine-ing into the deep from rapidly rising sea levels. It’s a pretty serious case and a super complex international issue. With a population of just over 10,000 and low interest in tourism, over 50% of Tuvalu’s GDP comes from foreign aid.

One of the most interesting things about Tuvalu, apart from fate at the hands of climate change, is its other means of making its economy look less like a Richter scale. For a steal-of-a-deal price, that can start at $3,000, you can own your very own ‘.tv‘ domain, which the island makes over $2.2 billion off in royalties in the same time it takes for your next birthday to come up.

The reason why I know way too much about all of this is because back in the dizzay when I was a wee little laddie, I once had to negotiate for the protection of Tuvalu in a UN simulation. I’ll never forget it. There is nothing like defending yourself when every finite molecule of your argument is being scrutinized. But defending something you’ve just learned in the time-span of a week is something else.

Every week at Lighthouse Labs we take the time to break into pods of five or six where your code gets grilled to perfection and your ego gets bashed around the room a little bit (just for funsies). Here, you and your developer-in-training peers can hash out the deets and define the logic for your code. As Lighthouse Labs Instructor Don Burks likes to say, “It’s like a peer review in science. Here you get a chance to defend your code like you would defend your thesis.”

In other words, this is the perfect opportunity to watch your logic fall apart like the Berlin wall – and I mean, it feels just as good watching it happen. When someone takes apart your code, it’s like watching someone dissect your brain, except they don’t just leave it like that. They challenge it, clean it up, take out all the frayed wires, and then sow everything back all pretty enough to introduce you to someone’s mother.

Like that time I built a virtual robot. I had to make sure his health decreased by its enemy’s attack points. I wrote out three methods that would: check the current health, decrease the health, and check if the current health was decreased by the attack points. This made sure that if the bot’s health was already at zero it wouldn’t be attacking dead metal.

Enter Lighthouse Labs’ kick-ass Instructor and ex-medival band member, Monica Olenscu, who after a millions of why’s and a mass interrogation that was filled with her glorious (sometimes maniacal) laughter, rewrote my entire code into three lines. Three. Lines.

Outside of the ass-kicking and humble pie, one of the best parts about breaking out into pods at Lighthouse Labs and doing a code review is the jargon and slang that flies around that absolutely has to be known to mankind.


These are what we call the slip-ups, the silly mistakes or the banana peel you could have probably avoided. Lighthouse Labs Head Instructor, Khurram Virani, refers back to those logic test you take in Grade 3. The ones with impossible questions and a mix of riddles, except you’re never supposed to get to them because if you read the instructions, you would have seen the “Please put your pen down, place your paper face down and step outside the classroom”. When a small portion of the classroom bursts into tears and another have their head down in defeat, the teacher walks in with a great big ‘Gotcha!’ smile.


Screen Shot 2014-06-13 at 12.47.20 PM

Errors are your friend, man. A sumo wrestler might sit on you because he doesn’t like how big your ears are. You’ll never know that until, for your added convenience, he proclaims something like, “DUMBO-SAN’. Suddenly you know exactly is on his mind. Those sweet words of proclamations are what we call stack traces or breadcrumbs. Unlike your passive aggressive significant other, these little thangs tell you exactly what they think your problem is.


I mean, what can I say except you have to watch this to get it.


WET and DRY are something we call TLA a.k.a. Three Letter Acronyms, which there are a ton of in code lingo. Writing Everything Twice or WET code, is the opposite of the kind of developer you want to be and the absolute antonym of the Don’t Repeat Yourself (DRY) mantra. Test Driven Development (TDD) and Behaviour Driven Development (BDD) are also TLA’s everyone familiarizes themselves with alongside FDD (Fear Driven Development).

Rubber Ducking

I wrote a Tom Hanks and Wilson reference to this once. Rubber ducking is this idea that good logic can be achieved by placing a rubber duck on your monitor and talking out your solutions to see if they make sense. Replace the rubber duck with any inanimate object and find yourself solving problems. Some of the best developers do this. You may or may not develop weird feelings towards it.

Technical Debt

When you move on before you get another piece of code working you create technical debt for yourself. This can get a little ridiculous when you’re a developer-in-training because you’re prone to feel like you can give up.

“Eat Your Own Dog Food”

The idea is that if you haven’t tried your own product, you can’t really talk about the way it works.

While we’re almost ready to jump into our final projects, the June cohort is about to jump straight into SQL. See you next week, where we see a new flurry of apps done by the almost-ready-to-grad peeps here at Lighthouse Labs. Check out the last time a grad made something super kick-ass:

[youtube id=”ijdEaRXymfE”]

‘The Ro Code’ is a Vancity Buzz exclusive blog delving into the course material, instructors and all round coding happenings at Lighthouse Labs. For more information on the next cohort, check out and get lost into a vortex of possibilities.


DH Vancouver StaffDH Vancouver Staff

+ News