Starting tomorrow until October 20th, it's EU Code Week 2019; that time of year to get young adults excited about programming.
Just as last year, several members of our team are taking part in one of the initiatives for that European Code Week; we'll be giving a workshop to 11 year olds by building a little robot with them next Thursday.
This blog post puts a spotlight on these initiatives and explains how you can help.

🇪🇺 European Code Week

During 15 days hundreds of activities happen all over Europe that want to celebrate creativity, problem solving and collaboration through programming and other tech activities.

You probably need little convincing that digital literacy is super important in today's world. Getting young adults interested in programming is one way of driving that.

"It's about Pia, who felt like she had to study law, even though she always enjoyed maths and playing with computers. It's about Alice, who dreams about making robots because her parents don't allow her to have a cat." -

The initiative started in 2013 and had grown to 44000 activities reaching 2.7 million people all over Europe by last year, all run by volunteers. The EU Code Week includes a.o. well-known initiatives like CoderDojo.

Code Week Participants


One of the other organisations taking part in the EU Code Weeks since a few years, has its roots in the hometown of Clarabridge Engage: WeGoSTEM.
(STEM is short for Science, Technology, Engineering & Mathematics, an acronym often used in education to refer to these fields, as part of a curriculum that is interdisciplinary & using an applied approach.)

WeGoSTEM's mission is to organise a fun workshop in as many schools as possible (mainly in Brussels & Flanders) to give as many 11 to 12 year olds as possible a first introduction to programming. Here's the robot we're building:

The Drawing Bot In Action

WeGoSTEM is a project of the NGO's Dwengo & SheGoesICT. Dwengo is organising teaching activities for people who want to experiment with micro-controllers, all around the world, and more specifically in socially-disadvantaged countries. SheGoesICT has as clear goal to advocate gender diversity in IT companies in Belgium.

The NGO's behind WeGoSTEM have diversity and inclusion in their DNA, so it's no wonder that also in the workshops they give, they focus first and foremost on reaching as many girls as boys, and focus on giving workshops in schools with many children from disadvantaged groups and rural schools. (In 2018, 29% of the children who participated in WeGoSTEM had a special socio-economic status (SES), while the average is only 20%.)

I've joined a few workshops that teached programming concepts to kids on Wednesday afternoons or during weekends, but there's no denying these are too often an affair for boys, and for kids from economically advantaged parents. For me personally, WeGoSTEM’s focus on inclusion, is a very big motivation to volunteer for this project.

By the end of the workshop the main goal is to have given every single kid a fun experience. (Not about building the most complex robot, or have the most advanced programming sequence ...) The only goal is to play around with a micro-controller and use the basics of a visual programming language.

✋ How it is to volunteer

So if you sign-up to volunteer, what actually happens? First, you indicate one or more dates you're available to give the workshop in a school, and area of preference. (This year, Jared and me are heading to a school in Bruges.)
There's also several training sessions around Belgium where the core team of WeGoSTEM explain the project, structure of a typical workshop, you get the time to build & play with the robot yourself, and meet the other volunteers.

When you visit the schools, you're a team of 3 coaches (of which almost always 1 has given the workshop previously).

  • 🗣 The workshop starts with a little chat with the class to see what they know and like and find exciting about robots. (Ideal place to test our dad-jokes about mowing robots ☺️.)
  • 🎨 In a next exercise it's about trying to show kids what it is to program: one volunteer kid instructs the rest of the class to make a certain drawing. At this point it often shows the importance of clear instructions.
  • 🔩 And then of course: building the robot (with Knex-like blocks) and a Dwenguino-board (a pre-assembled Arduino with several sensors).
  • 💻 Once the whole robot is build you help the kids to program the robot with Blockly. Blockly is Google technology that you can use & embed in other projects. (You can play with an online simulator of the Dwenguino/Blockly software over here:
  • 😄 By the end of the workshop the goal is to send every kid home with a smile and a drawing.

Oh, and in the afternoon, you do it all over again, for another class.

The whole experience - standing in front of a class room and having kids so eager to experiment with programming - is absolutely wonderful. And also quite exhausting (no need to convince me of the importance of good teachers, after only a single day in their shoes 😅.)

Maybe you helped inspire a kid to choose an education path focusing on STEM? Maybe you gave the teacher of that class the empowerment & tools to incorporate programming in some of their lessons? Maybe you helped show policy makers the importance of digital literacy and drive change?

A class with all their drawings ...

WeGoSTEM is 100% supported by volunteers in all participating countries. Workshops for the code week start next week, but there's definitely some free spots for coaches still. If you want to participate, check out the dedicated websites: WeGoSTEM Belgium and WeGoSTEM Greece.
After the Code Week, all volunteers can also always use the workshop materials needed to give an extra sessions in a school where you have a friend, kid or nephew or niece, so if you want to help us host a workshop, do let us know ...

Although the costs to run this project are very low (probably among the lowest euro-per-kid for STEM projects in Belgium), they can always use some extra help. WeGoSTEM is working with several partners that donate money, laptops, or help source volunteers amongst their employees.


Sometimes it's assumed that the frontend is a relatively harmless place to be programming. We've been proven wrong once again.

🔥🐶☕️🔥 This is fine

This is fine

For a few months now, we have been seeing relatively high loads on our web servers. The loads varied from around 90% of the total CPU power available, to a bit over 100% in peak hours. We assumed that this was normal and that our product was just being used more (which it was), and that this was a natural burden on the load on our servers. The approach we were going to take was to continue scaling horizontally.

Two weeks ago however, we noticed huge daily load spikes (up to 1000% of our capacity) during peak hours. We got alert SMS'es of Redis that couldn't handle the amount of requests, and saw Kibana logs of very slow user requests to certain routes, effectively rendering our application unusable at times. It was "all hands on deck" immediately, and we started digging. Before we could find out what was happening it stopped again, and the load dropped to what we assumed was "normal load". We found, also using Kibana, that there was a huge amount of calls to our /find endpoint, and so we decided to implement a rate limiter on those, to prevent our app from going down, and buy us some time to look for the actual issue. However, we couldn't see why that endpoint was hit so hard.

Kibana showing a lot of requests for one user in a short time frame

🐛🕵️‍♂️ Bug Hunting

A few days later, when we were hit with a huge amount of calls again (this time, they were ratelimited and not producing those huge loads on our servers, but we could see them in the logs and in Kibana), we noticed that most of them were coming from only a limited number of customers. We tried to work in our app as they would do, but couldn't reproduce it. After some time however, we noticed in the network tab of the browser we were working in, that the same call to the /find endpoint was done multiple times simultaneously! Bingo!

Or not Bingo? The code seemed to be fine: When we mount our inbox's react component, we use Sonora.on(eventname, callback) to bind a callback to a given websocket eventname (Sonora is an abstraction around When we unmount the react component again, we call, callback) to stop listening for those events. When such an event comes in, we would potentially need more info from the backend and a call to the /find endpoint is issued. It definitely looked like we didn't unregister the callbacks when unmounting that component, given how we saw multiple calls being made simultaneously in the console's network tab, whenever a websocket message came in.

Browser's performance tab showing lots of calls to the find endpoint

While everything was looking okay in the consuming code of the Sonora .on() and .off() methods, we concluded that something must've been wrong in the wrapper around itself. When looking inside the .on() method, we found out that there was a debugging statement added like this:

const Sonora = {
    // ...

    on: (event, callback) => {
            () => {
                console.log('some debugging here');

                callback.apply(this, arguments);

    // ...

As you can see, we wrapped the actual callback inside an anonymous function, and passed that on to's .on() handler. Now, when calling .off(), we sent along the original callback which didn't match the wrapped one, and nothing was removed. Since it's possible to have multiple callbacks for each incoming event, this resulted in the same callback being added time after time and not being removed. So we had basically made all our clients do loads of unnecessary calls to /find by adding a debugging statement! And believe it or not, this debugging statement was there for a while! (Thanks git blame!)

🔨👩‍🔧 Fixing it

The fix was easy enough: don't add that anonymous function.

The load on our servers dropped immediately when we put that small change into production, and not only during peak hours. It seemed that we had been on a tipping point. A few more users online at any given time, a few more open tabs with our application running in them. The servers constantly running at semi-high loads. And then we went over it. 🔥

Graph displaying the huge drop in load on our servers

Along the way we did some other optimisations:

  • we implemented a rate limiter on the /find endpoint
  • we disallowed to register exactly the same callback twice for the same event using Sonora.on()
  • we fixed a second bug in where we didn't remove the correct callbacks sometimes

😇💭 And they lived happily ever after

This was the tale of the small JavaScript bug bringing down the huge web application, a modern David and Goliath if you will. Frontend debugging tricks can take down your application! Every change is important, certainly changes that happen in code that's used very frequently. Some changes that look inconspicuous can over time become real bottlenecks. Tools like Kibana and the browser profiler & network tabs really helped us a great deal finding the issue, so don't forget what you have at your disposal.

We hope you enjoyed reading about our failures! Happy debugging! 👋


A few months ago, Mohammed joined our Clarabridge Engage development team for an internship and he has since then become one of our full team members. This blog post is about his story and how helped him find a place in our company, the technology industry of Gent, and ultimately Belgium.

“Three years ago I decided to leave my homeland, after an exhausting period of war, destruction and loss. I left my family hoping to improve my future and achieve my ambition. Belgium was my destination and by now I’m pretty sure that it was the right choice. When I got the Belgian residence I started to search for a job based on my resume in Palestine. I had graduated from the 'Information and Technology department' in Gaza, but I knew that I needed more experience and knowledge if I wanted to make it work here.” - Mohammed

My Experience at HackYourFuture

In his search for more education and building more experience, Mohammed was helped by the VDAB, Flanders’ public employment service. They suggested he attend the HackYourFuture course. HackYourFuture was founded in 2015 in Amsterdam, with the aim to enable refugees to build digital skills for a career in web development, facilitate the integration of newcomers, and address the shortage of qualified workforce in the IT sector, a shortage reflected by the amount of open positions we have here at Clarabridge.
In May 2018, HackYourFuture Belgium launched its first class in Belgium with 13 highly motivated students, Mohammed being one of them.

Mohammed recalls the course was a perfect match for him for several reasons:

“The course covered programming languages with interesting modules (CSS, HTML, JavaScript, Node.js, React). Each of the modules are taught by volunteer coaches with experience in the field of programming.“
“Because the courses were given on Sundays, it allowed me extra spare time to continue my Dutch lessons and driving lessons. And although I’m learning Dutch, the fact that the lessons were taught in English helped me too.”

The first class of HackYourFuture Belgium
The first class of HackYourFuture Belgium

During 6 months the students followed these lessons and for the last 9 weeks they worked on a project together in smaller groups.

“The coaches of HackYourFuture were as excited as we were, because for most of them it was their first time teaching. During the week, when we studied and worked on our assignments, they were always available through Slack to answer our questions.

When asked about what makes the HackYourFuture bootcamp stand out from following any of the online courses plentifully available through the internet, Mohammed points to the team aspect:

“By the final project we worked in groups of three, and every Sunday we divided the work between us. During the week we also kept in touch, and often we could use the HackYourFuture offices to work on the project.”

Mohammed’s project involved making a website for an institution from Brussels that would help homeless people and refugees to find the right information and help more easily. At the end of the course each team presented that project. At this graduation event one of our Clarabridge team members was also present.
Of course, for the students, it now became real. Mohammed: “We were worried about the next step, which would either be an internship or a job.” HackYourFuture assigned each student a mentor that would help the student take that next step.

Mohammed at the graduation
Mohammed at the graduation

Starting the internship at Clarabridge

This was the time when our company came into view for Mohammed. After having seen the projects at the HackYourFuture graduation event, we were impressed how far they got in only 9 weeks. We invited Mohammed for an interview, and his dedication immediately struck us. He explained what he was able to build, and what he learned at the HackYourFuture course, and this for us was the main deciding factor for offering an internship.

“I was lucky to get a four month internship at Clarabridge in Ghent, Belgium. I have learned new things every day, being surrounded by experienced and talented developers and engineers who are very helpful and very patient. They didn’t seem to get bored of my hundreds of questions.”

When an intern joins our team, we first of all look for the right project to work on. The ideal project is typically a stand-alone new feature (so the scope of it is clearly defined), challenging enough (from a technical and product perspective), should have as less external factors as possible (so there’s as little roadblocks as possible), involves enough existing components of the codebase (to evaluate how easy a person finds their way), and most importantly: a project that results in something that we can take into production and is visual to our clients and team. Having that success experience of having your code shipped into production is something we always strive for.

Mohammed started his work on an importer-system that would allow our customers to upload an Excel file with a list of account related settings. The feature would mean a huge time-saver for customers who want to configure several canned responses, tags, or saved filters at once.
Mohammed was assigned a specific mentor in our team as well (who helped on an almost daily basis), but the whole team got involved in reviewing parts of Mohammed’s code.

Mohammed’s first major Pull Request
Mohammed’s first major Pull Request

What I learned

Four months later, when this and several other projects of Mohammed's have been taken into production, we asked Mohammed what some of his main takeaways since his start in our team are:

  • 🏠 “When I started at Clarabridge, my main worry was that I had never written a line of PHP code in my life. I was wondering how I’d be able to get the hang of a complete language in only a couple of months. But actually, I quickly realised that learning PHP was the least of my concerns. Instead, my mentor and I focused a lot on how to write code using the principles of S.O.L.I.D. I probably learned more about programming trying to structure my code this way, than learning about language syntax.”

  • ✂️ “I always had to keep in mind that I was writing code for others. At some point in the future, another developer in the team will work on what I wrote, so I had to think wider and wiser, and take future uses and possibilities of my code into account. I refactored my code several times because of this.”

  • 🔨 “It’s sometimes tempting to fix an issue by writing code around it, but I realised that often this just causes a new issue. I try to to take more time to solve the problem at its root.”

  • 📚 “When I started my internship, I read the blog posts on this Clarabridge Developers Blog. Unfortunately, I had a hard time understanding some of the content. A month later, I re-read them and could already understand more. Until this day, I keep reading the posts which didn’t make sense at that time. Being part of an ambitious team who reads a lot, encouraged me to learn and read more too.”

  • 👯 “It’s often a balance between trying to find the answer on your own, and avoiding to be stuck for too long, and eventually asking for help. Time is valuable.
    I started to trust my teammates’ opinions, and worked on giving them a reason to trust me back. I learnt to avoid saying “I can do it alone” or “It is a piece of cake”. Instead I said “I’ll try to do it but I may need your help”. The team loves to help each other; so if you need help, just say it. When getting help from others, my teammates often had other personal perspectives. I learned to accept that, and picked from those that suited me. Eventually, by experience, you will have your own perspective.”

  • 👾 “Never underestimate another programmer, even if you know that you have more experience than him; always try to listen, discuss and understand. During the summer holidays, a talented 18 year old student joined our team. He didn’t know a lot about our application, but in a very short period of time he implemented more than 12 small improvements to the product. The whole team was impressed by what he has done. Because the improvements he worked on were smaller, easy to understand projects, I also learned from him by reviewing and checking his Pull Requests.”

That the most important lessons Mohammed lists are mainly about communication and how to learn from others, and the impact of that on how your code is structured, really show he’s become an integral part of our development team. It’s also a testament to the way a product is always built by a team of people (and not a single 10x engineer). So it’s no surprise that the project Mohammed is currently helping to build is one of our most requested features.

What is next, and how can you help?

“For me, HackYourFuture was my starting point. I was invited to be an assistant coach in the upcoming course - now at its fourth edition already. For me this is a great opportunity to pay back some of their generosity, and of course to continue learning.” - Mohammed

Know that HackYourFuture is run by volunteers. They are always on the lookout for people who work with challenging technologies in innovative companies. If you feel like sharing some of your knowledge with the students, maybe think about becoming a coach?
Helping as a coach can mean giving a few lessons, but also just being around when the students do their work, and trying to help out where possible.
Know that HackYourFuture is not only about programming, it’s also a real community supporting and helping each other to start a new career in Belgium.

HackYourFuture Coaches
HackYourFuture Coaches

If you’re a company interested in hiring some of the graduates, we hope Mohammed’s story helps. We can attest that the students are trained to perform well as junior web developers in a modern IT team, write clean code, and think like problem solvers. From this experience we especially remember the student’s eagerness to learn and start a development career.

Mohammed thanks

“Clarabridge is my home now, so one of my responsibilities is to make it bigger and keep it safe and shining.
With this post, I also want to thank everyone who helped me through my journey, by encouraging words or advice, or even a smile.
Thanks HackYourFuture and all of the coaches who showed the way for us, especially Frederik De Bleser who believed in me and kept giving me advice even after the course.
Thanks to my mentors at Clarabridge: Anthony, Toon and Cedric. And the other teammates who didn’t hesitate when I asked for help: Jenne, Gheerwijn, Thibaut, Thomas, Jared, Jasper, Hans and Erik. And thanks to Jurriaan who gave me the opportunity to be one of his team members, and for being a human before being a team leader.”

Want to join the course, or do an internship too?

If you feel like joining a HackYourFuture course, know they always accept applications. (The 6th course is starting in a few days!)
And of course, we also invite recent graduates or others interested in doing an internship in our team, to contact us.