4 takeaways from my incursion into geek territory…

She started learning code by herself before joining the Spring batch in Montreal with the goal of becoming a Product Manager. A week after the web development course in Montreal, here is what she learned from her bootcamp experience

On February 29, 2020, Samantha writes, at a time when most of the world was happily unaware of the confinement weeks ahead, and before anyone knew social distancing was even a thing, I handed my resignation to my boss. “What’s next?”, people asked. Well, how about learning to code?

Meeting many developers over the years had piqued my interest in this mysterious breed, coming up with creative solutions to seemingly intractable problems. So I decided to learn code myself. I applied at Le Wagon and it has been quite a ride!The Web development course ‘s impact on me has gone beyond everything I had expected. It gave me a different outlook on life and on how I approach things in general. I realised many of the techniques we were taught could actually be applied to day-to-day life. So here are 4 takeaways from my incursion into geek territory…

When coding, it’s easy to get lost in the details and to progressively lose sight of the big picture. As a novice, I would sometimes realise after a few lines of code that I had veered off course and was actually developing the wrong thing. One trick to avoid this is to start with the end goal in mind.

It might seem simple but just saying it will instantly clarify your thoughts and shine a light on potential inconsistencies. So whether you are applying to grad school or organising your next trip to Thailand, try those steps:

– Think long and hard about exactly what it is you want to achieve. Ask yourself: What am I trying to achieve? What does the end result look like? Can I picture it in my mind? Can I explain it to someone? 

For grad school, is your objective to get into an Ivy League, or are you open to other options? Your strategy might differ depending on your answer. For Thailand, is the trip meant to be a relaxed vacation on the beach, or more of an adventure? Again, the way you plan your trip won’t be the same.

– Put it on paper. You can either write it down with your own words or express it with pictures, maybe through a mood-board or photo-collage.

– Put it somewhere you can see it. Post a sticky note on your laptop, pin it above your bed or next to your bathroom mirror… You need to see it every day. Like the captain of a ship, you need to be reminded of the direction you’re going so that you don’t inadvertently get derailed without noticing it. This is your map.

Incidentally, I realised later on it was one of the habits recommended by Stephen Covey in The 7 Habits of Highly Effective People.

Ok so, you have a blueprint and you know where you’re going. But having a whole algorithm to write can feel daunting. The task at hand is so massive, it feels like sitting at the bottom of a big mountain you need to climb. Or, as our teacher Stéphane would say, like trying to eat an elephant.

Pseudo-code is the sentences in plain English that you write directly in your text editor before you start coding.

Let’s say you want to code a simple program that tells the user whether or not he is allowed to enter a club. How would you write the pseudo-code?

– First, you would need to find out the user’s age.

– Then, you would need to define an action for every alternative. If he’s younger than 18, tell him he can’t get in. And that’s the end for this user. If he is 18 or older, he can move on to the next step.

If he’s over 18, you should probably check that he respects the dress code for this particular club. Again, this will give you 2 alternatives. Either he doesn’t and that’s the end of the process for him. Or he does and he can move on to the next step.

– Finally, if he’s over 18 and appropriately dressed, one last thing to check would be if he’s intoxicated or not. If he is too bad for him, it will end here. If he is sober, good! He can finally get in.

Pseudo-code is your recipe. Now you know exactly which steps you need to take in writing your program. It breaks a complex algorithm into smaller digestible pieces. All that is left to do is to follow the steps you outlined for yourself.

Early on in the bootcamp we were taught to get in the habit of testing our code extremely often. Doing so ensures you narrow down exactly what line is causing the code to break. If you don’t test regularly, your code might be broken but you might not realise it for a while.

Then it will be much harder to debug: you will have to undo every action done recently until you find the problematic one. It is like baking a cake and tasting it after each ingredient you’re adding.

I would often struggle with this: as a beginner, it is already so hard to get your code to work, that you don’t really feel like finding out more stuff to fix…

Without it, you can’t find out what’s wrong and may keep going in blissful ignorance… until the problem comes back. And this time, it will be much harder to fix.

In life, too, this actually proves extremely useful. Say Anna and Mike are two college graduates who are on their way to becoming teachers.

– Mike is giving English classes to his foreigner friends on the side and teaches at a summer camp every summer. Over the years, he has collected a lot of feedback about his teaching. All this “testing” has also comforted him in his decision to become a teacher: he likes to teach, and he’s good at it.

– Anna, on the other hand, will go on to get her masters and eventually start teaching in a middle school, only to realise a few months in that she’s not great at it and not even that excited by it.

The cost of testing is not that high when done early. Had she tested her motivation and talent early on, Anna could have easily changed course and found a better-suited career. But with any project, the cost of going on too long without testing gets higher and higher as time goes by.

So, in life and in code, test early and test often.

Granted, failure in life does not come with an error message. But figuring it out yourself is part of the fun.

You know exactly what result you are aiming for, you are taking it one step at a time, you are testing at every turn… But something has come up and upended your whole plan. Your map is no longer relevant and you’re lost. Two tricks here:

 – Rely on your foundations. During the bootcamp, we would more or less learn one key concept every day. Each day was building on the previous, and after a few days you would have so much new information that your brain would start to get really confused.

My strategy then was to go back to basics. What did I know for sure? You can’t walk on shifting sands. When everything around you is collapsing, go back to what is solid, and take it from there.

– Talk it out. Developers use what is called “rubber duck debugging“. They place a rubber duck next to their laptop. When confronted with a bug, they will then proceed to go through every line of code with the duck, explaining to him what each line does. And then…. “at some point you will tell the duck what you are doing next and then realise that that is not in fact what you are actually doing.”

So, when faced with a problem, in code and in life, talk it out! It has a secret power that will reveal any inconsistency you had been overlooking. If you don’t own a rubber duck, take your cousin, your wife, your 5-year old, and explain to them the situation you’re facing. All they have to do is sit there and listen. The solution will jump at your face.

You can check the original post on her LinkedIn.