What made you interested in working with us and how has Omise changed in the last 7 years?

I’ve been very good friends with our former CTO, Robin, for a long time. Despite attending the same high school in Belgium, we first met at our previous job here in Bangkok. He called me one day in early 2014: “Hey, I’m starting a new project. Wanna join?”. I came for an interview with him, Jun(Founder) and Donnie (CEO) a few days later and they told me everything about their dreams of a social eCommerce platform. Their excitement was contagious and won me over. I pretty much immediately wanted to be part of this journey!

Omise has changed a lot since then! The office used to be barely larger than our current kitchen. There were 6 of us and we all had to wear many hats. Did you know Donnie was the housekeeper?

In many ways, we were a scrum team. All working together towards a common goal and vision. I’m glad to see this sense of ownership coming back to us in the past few months.

The most drastic change is the time we completely switched our direction. For the first half of 2014, we were building an e-commerce platform. At that point, we needed a payment gateway but could not find any that really worked for us. We went through 3 phases:

Joking: “Let’s build a payment gateway!” 🤣

Questioning: “Let’s build a payment gateway?” 🤔

Determination: “Let’s build a payment gateway!!”😃

And that’s how Omise as it’s known today was born.

What do you like the most about working with Omise?

Besides the amazing coworkers: the fact that we’re constantly challenging ourselves. We’re building our own path. New payment technologies are booming now, and we’re not afraid to take them on.

Being with the company since the very beginning, what is your proudest moment here so far?

Our first live charges! Just a few months after shifting to building the payment gateway, we had our first live charge on time for the Echelon event. That’s when I realized: we did it! We are a payment gateway!

How would you explain what an API is to a 5 year old?

An API (Application Programming Interface) is how programs let other programs interact with them.

For example, Facebook probably has an API that allows you to retrieve the number of friends you have.

I once heard this good analogy: What’s the easiest way to get a pizza? Ordering one! The 3 relevant steps here are:

• Request: “I would like to order a pizza”
• Process: The restaurant prepares your pizza
• Response: The pizza gets delivered to you

You could try going to the restaurant, walking in their kitchen, learning how to make a pizza and head back home with something to eat. But no one’s going to be happy about that. By ordering, You don’t need to learn how to use their appliances or how to make pizza You don’t make a mess in the kitchen Your pizza probably tastes better!

The same applies to APIs, with the same 3 steps:

• Request: “Facebook, tell me how many friends I have”
• Process: Facebook counts your friends
• Response: The number of friends gets returned to your browser

Similarly, no one would be happy about you doing all of that yourself. By using the API,

• You don’t need to know how Facebook is programmed
• You don’t make a mess in their systems
• You get an accurate response

What’s the best environment for you to code in?

Coding can be like reading a good book: You tend to forget where you are and what time it is. In that sense, the physical environment doesn't matter that much to me as long as I'm not uncomfortable or constantly disturbed. In the corner of a coffee shop? Sure. On a plane? Why not. Outdoors? Works for me. Having a good idea that I am excited to implement is by far the best (mental) environment!

If you could create a video game for yourself, what type would it be and how would you name it?

I am quite fascinated by Dwarf Fortress. The amount of detail and stories possibilities is mind blowing. There are entire youtube channels dedicated to narrating stories that emerge in-game. It seems like a game that’s both a lot of fun and infuriating to code! I would therefore attempt a Dwarf-Fortress like called... Goblin Bunker? Not that I could come close to where the original is now. It’s more about the journey and the process.

Are there any podcasts, books or blogs within tech you swear by?

One of my favorite books is “99 Bottles of OOP”. There’s something for every developer's skill level. It taught me concepts I was not familiar with and also formalized those I instinctively knew from years of experience so I can better share them with my team. On top of that, the challenge offered by the book is a lot of programming fun.

On the topic of small, satisfying programming challenges, I highly recommend Opus Magnum. It’s a puzzle-driven game that scratches a lot of (my?) programming itches and adds a visual factor to it. The goal is to build and program an alchemy machine that manipulates atoms to create the desired molecules. You usually come up with a prototype that gets the job done. Then it’s up to you to refactor and relentlessly improve your solution by making your machine smaller, cheaper and/or faster.

I don’t have a favorite blog, but I keep a collection of articles I particularly like. One that I often recommend is “Making wrong code look wrong”. The idea is that we can have coding conventions that make some mistakes very hard to miss. Let’s take a look at a simple example. Years ago, this seemingly innocuous line in our Charge API test went unnoticed. It ensured that the customer in our Charge response was the correct one:

assert_equal customer, response[:customer]

The test passed, and the code was released. However, this is what our API started returning:

{ "object": "charge", "id": "chrg_test_no1t4tnemucod0e51mo", "amount": 12345, “customer”:”#<Customer:0x00007fa63c034280>” }

That’s an internal Ruby object ID, not the public Omise Customer ID we expected!

If we take the simple convention of hard-coding expected values in our tests, this type of mistake becomes impossible to ignore:

assert_equal "#Customer:0x00007fa63c034280", response[:customer] # Clearly wrong assert_equal nil, response[:customer] # Not what we intend to test assert_equal "cust_test_no1t4tnemucod0e51mo", response[:customer] # Correct!

We have adopted many of those conventions that increase our confidence in our code and are now invaluable.

In your opinion, what is something revolutionary that will happen in coding in the next 10 years?

I’m curious to see the future of quantum computers. To me, that’s a technology shrouded in mystery that could have a huge impact in very specific domains.

And finally… tabs or spaces?

Coke or Pepsi? Doesn’t matter to me. Just don’t mix them, because who does that?