Working on Rails in a company where the main stack is not Rails

Why I choose to come to Voodoo

After spending four years at my previous company, I decided to join Voodoo, having heard good things from a friend and former colleague, about the atmosphere, people, not to mention the great working conditions.

At that time, I was working with Ruby on Rails, and to be honest, I had the feeling that I would not learn much more by sticking to this stack. By joining Voodoo, they suggested that I broaden my skills with Node.JS.

In the Ruby community, Javascript does not have the best reputation, as it is a language so far removed from the Ruby philosophy. But the ubiquity of this language, and its constant ameliorations, made me want to really try my hand at it.

The recruitment process reassured me in my choices, particularly thanks to discussions I had with the recruiters, managers and my future colleagues. What stood out to me was how helpful and motivated everyone was.

In the first few months I saw Voodoo’s technical stack progress really quickly, it got increasingly rationalized and formalized as we set up the best practices. I think that it is an interesting point to move from a seedling technical stack that was growing quickly, to a technical stack of a more mature company — you simply do not code in the same way.

Autobid

After a couple of years at Voodoo working with Javascript I had the opportunity to work on a very interesting project named Autobid, which has a back office written with Ruby on Rails.

Autobid is designed to help Voodoo get as many players as possible downloading and playing our games by bidding for adspaces, something that was previously done manually. At Voodoo most of our acquisition comes from in-app ads for our games and the amount we are willing to pay for an installation depends on how much revenue a game is able to generate. For example if an installation generates $1 in ad revenue and we have a margin target of 50% we will be willing to bid at $0.50.

The number of factors to take into account for those bids are quite numerous: the individual game, the country in which its being played, the ad network used to fill ad slots, the ad campaign in question, the app where the ad was displayed…. Each of those factors may have a huge impact on the value of an installation and they all vary with time. Just to give one trivial example: in general an American installation is more profitable than a French one because in-game ads provide more revenue in the US.

We used to do all of these adjustments manually, using a pretty simple method to calculate our forecasts, but that limited the volume of tweaks that we were able to make and thus the quality of our bidding.

Now with Autobid, our goal is to automate the bids we make: this platform uses machine learning to make the best possible forecasts at the lowest level possible, giving our acquisition teams tools to monitor and manage our bidding process, and send our bids directly to our partners.

As a backend developer I do not directly work on the ML parts of the platform but it’s still quite satisfying to work with a team of dedicated data scientists. We all know that, because of the hype around ML, many tech companies tend to oversell their use of ML, but here at Voodoo there is a really interesting practical use case for ML, with an immediate impact on what the company does.

We should not be obsessed by any particular language, just be flexible

So what did I learn by going back and forth between Ruby and JS?

First, they are not so different. They are not exotic or deprecated languages used in some very specific context.
For example, if you use Cobol, you cannot really improvise as a developer. But the reality is that when you get into web languages, they tend not to differ that much. Ruby and JS are languages that have the same basis, and moving from one to the other — in my opinion — should not be an obstacle.

In an ideal world, you choose a language because you have a specific issue to solve and that is the most appropriate language for this problem. In our specific case, we chose Rails because we had a small application that needed to be launched quickly, and Rails is very useful for that. It can be seen as a prototyping language. Rails is a framework with several arriving tools. In contrast with Node.JS, you need to take time to ask yourself as you are going to manage your Front or Back-End for example, before starting to code. To get a functioning prototype ASAP, Rails is the best choice. In my mind, a good developer should be able to shift from Node.JS to Rails without a hitch. There’s no need to be stubborn when it comes to the choice of language, if the project makes sense and is impactful.

At Voodoo, one of our values is “push for speed”. That is why I immediately decided to move from Node.JS to Rails, with the idea to accelerate the delivery of projects with a big impact on the business. The project with a massive impact right now is our Autobid project, and I think that is really cool.

Apart from the fact that it is a Rails project, it is also very different from what I have done before in other key aspects, because the heart of the project is different. Building this platform was something I had never done before, so it was a real differentiated problem. Also there was the constraint that there were not a lot of Rails developers at Voodoo.

But in my personal capacity, what I liked beyond the question of the choice of language, is what you can actually create with that language and that — for me — is far more important.

Being the only Ruby on Rails engineer, what a challenge!

What’s important when you’re alone on a project, beyond the workload that it represents, is what you allow external people to do. Best practices dictate that your code should be easy to read for other developers when you are not there, for any reason. As the sole Rails programmer in the team, if I have a difficulty, I cannot just give it to someone else. On the other hand, I am truly the owner of my projects, with the licence to be autonomous and creative. I do things my own way, with deadlines that I have established to deliver projects. This is true freedom.

With regards to the technical quality, on the other hand, it is important to write clear and robust code, to be sure that anyone can take over the subject. The clearer and more legible the code is, the easier it is to maintain. If ever there is a bug, it can be quickly managed because anyone can find the source more easily. Obviously, the quality of the code is always highly appreciated because it makes it easy for the project to be taken over by anyone.

That is also the thinking behind the choice of Rails, we have decided to prioritise the maintenance of the code, and the ease of modification. The simpler and more precise the code is, the easier it is to add things on top of it. Having someone on my team to help me to improve the code, would be very precious.

The Team

The fact that I am the only one using this language, does not mean that I am excluded from the rest of the Engineering & Data Business Unit. On the contrary, I am integrated into all of the meetings regarding platforms because in our work there are many problems and solutions we can share that are not linked to the language. For example, we might have common commit format or architectural questions. You could say Rails is a framework with strong opinions — what I mean by that is that in Rails there is a certain way to do things — I am very present for the rest of the Unit regarding important questions linked to the language: what do we want to do with the infrastructure, the DB… We have a meeting once per week, in the form of public speaking and presentation (following common documentation and templates).

We are looking for senior and experienced tech engineers to join us to help deliver our ambitious roadmap on a project that is central to Voodoo’s mission.

There may not be other Rails projects at Voodoo, but there are a lot of Node.JS and Java projects. We are a multi-language company, even if the main language used here is Node.JS. My goal for the arrival of our newest team member is to train them and to support them in a full audit of the Autobid project.

My latest project, at the very heart of Voodoo’s strategy

Autobid is one of the most central tech projects here at Voodoo. When I talk about Voodoo with my peers, I say that we are not only a mobile gaming company, but also an advertising company. In terms of our everyday work — and what makes the difference with other market actors — is that we monetize our games.

Autobid represents the heart of Voodoo monetization. It makes sure that we optimise the value a game brings us. That is something that we cannot externalize. If we externalized the principle of monetizing games, people wouldn’t come to us for our internal expertise on the topic. That is why this project is central to Voodoo’s strategy because it brings a real added value to the Studios. When they give us a game, we are sure to make it profitable, by monetizing it as well as possible and enhancing it according to first costs brang. The team has grown enormously over the past 2 years, we are now working with data scientists, data engineers and data analysts, their jobs are very important and strategic. As the stakes at Voodoo are often high — and my team plays a huge role in value creation here — the work we do on a daily basis can have a huge impact.

I truly own my project in a broader sense, not simply one backend developer among many, Autobid is my application. I have to make sure that everything works perfectly, in terms of infra, backend, frontend, and that also includes the data, which means both a Python part and an SQL part. At other companies, when you are a backend developer, you are probably going to produce APIs all day long. This is definitely not true at Voodoo, where you need to have a certain knowledge about the job, and also a lot of technical skills (being comfortable with a bit of everything: backend, frontend, infra, data). In my opinion, in what I do, there is no difficulty thinking about software problems, we need to do more complex and out-of-the-box thinking, in terms of “how to make sure that many different things are harmonized and work all together”.

I’m not going to lie, joining the team means learning a lot of things. For someone who has never worked on Rails before, it is a great opportunity to open your mind to new skills (infra, Python, SQL, Node.JS) and to be updated on new market trends and languages. There’s no need for you to have professional experience on mobile, having the right mindset is much more important.

If you want to join my team and participate in a very impactful project, at the heart of Voodoo’s business, please apply on https://www.voodoo.io/careers/ and don’t hesitate to reach out to me directly on LinkedIn.