Go to lewagon.com

4 takeaways from my incursion into geek territory…

For 5 years, Samantha organized hackathons all over the world for big corporations such as L'Oreal, LVMH or Air France. That led her to develop a love and curiosity for the tech world.

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

Samantha and her team during the bootcamp

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…

1. Have your end goal in mind

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.

You should be able to sum up your desired result in one sentence. In code, we would say something like “I want x to happen when a user does this action”.

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.

2. Break your project down into small tasks

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.

So, how exactly do you eat an elephant? One bite at a time! Here too, developers have an interesting approach we can steal: pseudo-code.

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.

Apply this to your next project: break the big task into a bunch of very small ones. The nice added effect of this is that you shouldn’t procrastinate as much, since every step is tiny and can be done in a relatively short amount of time. Baby steps!

3. Test your code earlier rather than later

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…

But when troubleshooting with the teachers, I realised they were actually seeking failure. Why? Because bugs come with an error message that more or less tells you what 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.

But with any project, the cost of going on too long without testing gets higher and higher as time goes by.

– 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.

4. When it doesn’t work…

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.

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.

– 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.

Our users have also consulted:
Pour développe mes compétences
Formation développeur web
Formation data scientist
Formation data analyst
Les internautes ont également consulté :

Suscribe to our newsletter

Receive a monthly newsletter with personalized tech tips.