EW S5E6                Transcript


EPISODE S5E6


[EPISODE]


[00:00:07] JE: Welcome to Elixir Wizards, a podcast brought to you by SmartLogic, a custom web and mobile development shop based in Baltimore. My name is Justus Eapen and I’ll be your host. I’m joined by my mesmerizing co-host, Sundi Myint and my other-worldly producer, Eric Oestrich. I will have you notice that I used alliteration on the last names this time, so we are mixing it up.


This season's theme is adopting Elixir. Today, we're joined by the CEO of Duffel, Steve Domin. How are you Steve?


[00:00:37] SD: Hi. Very good. Thanks for having me on the show.


[00:00:40] JE: Steve, we're so glad to have you. You are also the organizer, or one of the organizers of the London Elixir Meetup. You're technical. We saw on your LinkedIn, you have been a programmer for a long time. I’m going to ask you how you got into programming, but first, we're going to jump right into some Elixir, because we were talking before the show started about José Valim, who invented Elixir and some of his cryptic tweets that have been coming out lately. What is he tweeting about and what are you gathering from these tweets?


[00:01:12] SD: I mean, yeah. There's just a lot of tweets recently about benchmarking numbers, binaries. I know a lot of people at Duffel are asking the question like, “Hey, do you know what's happening with José?” There's clearly a secret project going on. So José, if you hear this, it's time to reveal it.


[00:01:33] JE: Calling out José Valim on Elixir Wizards. That's definitely going to make this go viral. What about you? Can you tell us a little bit about yourself, how you got into programming? We'll get to Duffel. I can't wait to get to Duffel, but I want to hear just about you, how you got into programming, how you learned to program. Tell us about it.


[00:01:48] SD: Yeah. I think I started around 14 or 15 maybe. I was in high school. We had this project, this assignment to build this robot that would follow line. It was very popular in France. I think a lot of schools gave that as an assignment. I wanted to build a website to put some pictures of the robot. I think that's how it all started.


Then there was a website in France to learn programming called Site Du Zero, which translates to ‘Website for Zeros.’ They just run you through all of the steps to build your first HTML website. And then they added courses on JavaScript. Yeah, that's how I got started. Very quickly, I ended up getting into Flash and ActionScript. For a long time, I was actually an ActionScript developer.


[00:02:38] JE: I feel like Flash has come up on the show recently. I’m a big fan of Flash. It brings me back to my glory days when I was six. You were in a robotics program initially. That's amazing. You built a robot before you built a website. That to me seems amazing. Do you remember what sparked your interest? Was it a mandatory course requirement, or was it an elective? Just what about programming made you excited?


[00:03:03] SD: No, so it was mandatory. I was following a science track, science and technology track in high school. That was part of the courses. I can't really remember. The robot if you saw it, it wasn't very impressive. I mean, maybe I’m making it sound like it was bigger than it was, but it was very simple. Yeah. That's how it all got started. The website, I really — we had internet at my home and seen some websites and I was fascinated by it and I wanted to build one. That's how it all started.


[00:03:36] SM: Did you have any resources that were really helpful for you? I know like, today, there are a lot of really great resources for kids to learn, even as young as two or three-years-old. I’m curious as to when you were learning, what resources were out there for you.


[00:03:51] SD: Yeah. Aside from the website, I mentioned the Site of the Zeros. There wasn't much back then. I think that was the main thing, to be honest, because there's no books, or at least, not that I could find in the city that I was living in. Yeah, all just that single website that had the course on HTML. Nothing at school as well, which was yeah, nothing.


[00:04:13] JE: Do you remember your first paid job in programming?


[00:04:18] SD: Yeah, I do actually. It was a freelance job. I was tasked to build this ActionScript program, this Flash program. Actually, it wasn't even Flash, to be accurate. It was Flex. Flex was this technology from Adobe that was meant to be used to build a rich application, as they used to call it back then. It was a suite of components that — it was essentially a framework that you could use to build the rich applications. I mean, Google it after the show. It's proper old school. Yeah, I got that job where I was tasked to build an application in Flex to sort through hundreds and hundreds of photos for some research department in France.


[00:05:04] JE: This is way off topic, but I’m curious if you can maybe explain some of the Flash ecosystem of the time? Because now, it's come up a few times on the show and I do think, actually placing the technological ecosystem context is interesting for people. I remember Flash being Macromedia Flash. It was supposed to be multimedia animations, sounds and everything, but it would run in the browser. I was seven-years-old at the time, so I don't really remember that stuff very well, but I’m curious if you can maybe tell us a little bit more about that ecosystem. I’ve never heard of Flex before. ActionScript I have heard of. Can you maybe just tell us a little bit more about that ecosystem in that world?


[00:05:44] SD: Yeah, sure. I mean, it's been a while now. Yeah, Flash was the Macromedia runtime for, I guess, rich applications, or rich animation. Adobe bought Macromedia and then it became an Adobe product. The language back then was ActionScript 2. Then Adobe bought it and it started the development of ActionScript 3, which, if I remember correctly, was inspired by Java, more than it was by JavaScript. Which, for ActionScript 3 was — that was the origin.


After a little while, Adobe started developing this technology called Flex. It was a framework that was built entirely in ActionScript 3, that had a lot of components. I mean, it was — in many ways, like React before the time, or it was more like, maybe React is not a good analogy. It was just this high-level framework that would sit on top of ActionScript 3 and Flash.


Then, they even had that integrated development environment that was built on Eclipse, which was called Flex Builder. You had the coding view, but also — I can never pronounce that name in English. ‘What You See Is What You Get,’ like WYSIWYG. Or an environment where you could drag and drop components and build your interface in this way, in Flex Builder. Yeah, that was it.


[00:07:15] JE: It's so bizarre to me that at one point, Adobe had such a huge impact on the world of web development. Once upon a time, Macromedia Flash was literally everywhere. And now, first of all, I haven't heard anyone talk about it in a live development sense in at least a decade. Now, I’ve heard more people talk about Cold Fusion, which I don't think is related at all.


[00:07:37] SD: There was a lot of when Adobe bought Macromedia and at that time, there was a lot of interoperability between Flash and Cold Fusion. You could use Cold Fusion for the back-end to your Flash application. They had all of these pre-built modules for forms and a bunch of other things.


[00:07:58] JE: Yeah. Not anymore though, I’d expect. I mean, Cold Fusion, I feel it's still pretty modern. People use Cold Fusion. I mean, a few years ago, someone was asking me like, “Do you work on Cold Fusion?” I was like, “No.”


[00:08:11] EO: I’m not sure I’d call Cold Fusion necessarily modern, but surprisingly, they did still have a virtual conference this year. It's big somewhere.


[00:08:21] SD: Wow.


[00:08:23] JE: Let's get to talking about Duffel. Duffel's one of the most interesting startups, I think, around right now. You started in 2017, is that right?


[00:08:31] SD: Yeah, correct.


[00:08:32] JE: What is Duffel?


[00:08:35] SD: We are essentially rebuilding the software stack for the travel industry. If you've ever been on a plane, or checked into an hotel, which seems a very remote experience nowadays. Back when we used to do that, all of the software that sits underneath this experience has been built in the 60s, 70s. Very, very old technology that runs on mainframes.


The travel industry is not the most modern industry in the world. It's been very hard for people to innovate. If you look at the experience that we have in online travel, I mean, since the first generation of online travel agencies, we can't say that things have changed much. There's more websites and more options to buy flights and book hotels, but we can't really say that the experience is better.


In many ways, I mean, COVID has highlighted a lot of the deficiencies around cancellation and refunds and a lot of that has been manual and people have had a lot of pains. What we wanted to do with Duffel was build a newer, more modern set of software for the travel industry. Our first product is the flights API, which is an API that lets you search, book, manage, cancel, buy ancillaries, buy seats for the flights industry.


[00:10:01] JE: When did that API become publicly available?


[00:10:05] SD: We launched it last year, in September last year. Initially in a closed beta. Then we opened sign-up on the API in April 2020, so a few months ago.


[00:10:16] JE: Oh, my gosh. Can you talk a little bit about a travel tech company debuting its flagship product in the middle of a global pandemic, wherein like, 80% of flights have been cancelled?


[00:10:28] SD: Yeah. We actually had a timeline that was much longer. When COVID hit, we decided to accelerate everything, because our reasoning was there aren't going to be that many people that are looking at plugging into a flights API right now. What best time there is to launch something and see what breaks and start gathering feedback. It actually has been super valuable, because instead of experiencing just a large number of customers coming and starting to play with the APIs and all things break, which naturally would have happened, we've actually had that slow ramp up and it's been super valuable for us.


[00:11:07] SM: Can you talk a little bit about you mentioned, the tech is ancient from the 60s and 70s. I worked in the travel software space a little bit too and I didn't work on the integration side. But we heard about it all the time; our integrations team had so many pain points integrating. Can you speak a little more to what that system looks like and how your API helps alleviate those pain points for teams?


[00:11:33] SD: Yeah. Without going into too much details, the way the travel industry works today — and actually, I’ll focus on the airlines, because that's what we do the most now. It makes things a bit more focused. So the airlines run these massive software systems called Passenger Service Systems, or PSS. And that's a suite of different components, software components that do anything from reservation, departure control, loyalty programs, revenue management and a bunch of other things. This is the stack that has been built ages ago.


There is a layer on top of that that's called a GDS, which is a Global Distribution System. There are companies like Amadeus — that’s very big in Europe and Sabre in the US, that connect to all of these different PSS from airlines, so these central reservation systems. They offer APIs, but these APIs have been built many, many, many years ago and are not very easy to work with.


They are even very difficult to get access to and not well documented. It's not rare for us to receive documentation in a suite of Word documents. So 20, 25 Word documents with tables that really scream to be displayed on a large screen were constrained by the width of the Word page. Which is really, really not ideal. Where we come in is that we connect directly into the reservation systems of the airlines, but through a newer set of APIs that the airline have built recently. That is supposed to be very modern technology, but it's XML on [inaudible 00:13:25].


[00:13:26] SM: How recent is it?


[00:13:28] SD: Last 10 years. So not super recent. So we connect to these new APIs which are much better than the old APIs that the GDS are using. On top of that, we've built our API, which is what you would expect today as a developer from an API, so Rest, JSON documentation is available online. And actually, well-documented, or decently well-documented. All of the tools and all of the experience that you would expect as a developer today, we bring it to travel.


[00:13:59] SM: Yeah, that's amazing. For some context, I think something — one of the fun facts that I learned when I was working at my travel startup was — that I think you actually have a picture on your blog about what Sabre, one of these ancient terminals looks like. When, if you go to an airport and you walk up to the terminal desk and the flight attendant is putting something in behind the screen and you actually get to see that screen, I think that's what you show on in your blog post.


There were tons of tests. Developers have been trying to revamp the system for decades now, right? There still is nothing faster than a trained flight attendant, or a trained airline professional who can use the Sabre directly in that terminal. There's still nothing faster than a human trained to do it. We as humans have been trying to revamp the system for decades and it's super cool that you are actually making some progress towards making that easier for developers. It's super cool.


[00:14:54] SD: That's part of the reason why I was focusing on the API side. I mean, beyond, I think, the fact that it's a much nicer position to be in, like, building the API and letting people innovate and build these replacements for the Sabre and Amadeus terminal. Yeah. I mean, it takes three to six months to get trained on these terminals. When any large travel agency comes and says to their travel agents, “Hey, we're going to replace your terminal that you know very well with that slick UI that has been built very recently and that looks amazing.” Most of the time, the reaction is just cries and screams and they don't want it.


[00:15:36] SM: First, I guess, I want to ask, how did you come up with the idea like, this was the problem in the world you wanted to solve? Where did the idea for Duffel come from?


[00:15:45] SD: I used to work for a payments company based in London, called GoCardless. Back there, I started this site project with a few friends around travel. It was a website called Next Weekend. It was just the most — unambitious act project you can think of. The idea was as a user, you would select a couple of criterias, architecture, beachery days, food, shopping, whatever. Then the website would generate weekend getaways. Flights, hotel, activities, free suggestions for destinations you can go to, everything lined up. Just one buy button and then everything will be booked for you.


When we started on that project, very naively, we thought, “Well, the recommendation engine, that's going to be painful. I mean, how are we going to get the data in order to make nice recommendations? Then the booking engine, once we have the destination, that's going to be super easy. I mean, there must be an API somewhere. We work at an API company. I use Twilio and Stripe and all of these APIs provided many times over. Surely, there is the same thing in travel.”


Obviously, as you can imagine, we were very, very wrong. We ended up scraping Tripadvisors and building the recommendation engine using that. Then, we arrived at the booking engine parts and we’re like, “Okay. Flights API in Google.” The only thing that comes up is Amadeus and Sabres. We go on the website. Very corporate websites. No signup. Not even a presentation of the products. Not even a cold sell. At the very least, someone to reach out to. No. It's just all corporate, fuzzy words, and “Changing the future of travel through better technology.”


We were just, “Okay. That's not going to be an option.” We ended up settling on that product from Google called QPX Express. So Google had bought this company back in Boston called ITA, who was doing a flight shopping engine. They were forced, I think by the FTC during the acquisition. I think it's the FTC. I’m not so sure, with all the federal agencies in the US, but they were forced to leave a version of the flight shopping engine available for the general public for seven or eight years after the acquisition.


What I did is took that amazing flight search engine called QPX and they created a slim-downed version of it called QPX Express, which was very expensive. 50 cent per search request. So if you're running any decent travel website, you will just get killed by that price. I mean, it wouldn't work. And you couldn't book. You couldn't redirect to the airline's website. The only thing you could show is just there is a flight that departs this day, this time, and that's it.


We used that to be the first version of the website and that was the first foray into the pains of the travel industry. Came back to it a few years later. Wanted to build a new version. Nothing had changed, and so that’s when Duffel got started.


[00:19:00] SM: Like I said, it was very brave of you to tackle this. This is something that teams and teams and teams of engineers have tried to tackle and have not had great luck with. How did you decide to use Elixir to tackle this problem? Or did you not? Did it come up later?


[00:19:14] SD: No. Actually, from the get go, we started with Elixir. Elixir back at that time was my language of choice for anything that has to do with web and APIs. That was the language I was the most familiar with. And just started building the first version of the API with that. It was the language I was the most productive with and that I enjoyed. And also, I thought it was a language that was very well suited to the problem that we were going to face.


[00:19:43] SM: Yeah. I was taking a look at your API. It's beautifully documented, by the way. Hats off to you on that. I noticed that there was a lot of, well, being familiar with flight data, I could recognize it when I saw it. But having now worked on Elixir projects, I was recognizing that maybe the data model is a little easier to scope out in Elixir than maybe another language. Can you speak to how you're using Elixir to leverage, or sorry, how you're leveraging Elixir to benefit your data and the way you organize all of that?


[00:20:18] SD: Yeah. So one of the main benefits of using Elixir is — before the data is that we get a request from our API consumers. Then we need to span out to potentially dozens of airlines in order to get their search results. Obviously, that's the language that Elixir is really — that's a problem that Elixir is well-suited to solve.


On the data side, we interestingly, maybe not, we used Ecto from the get go for all of the data that we received from the airlines. The schema-less version of Ecto. The idea behind that was well, we have all of these data that we get back from the airlines. We need to perform some validation. Maybe not all of it is good enough for what we'll do with it. Ecto seemed a natural fit.


We're running into some pains now, because we've pushed it too far, I think, the data that we get back from the airlines, the responses are massive. We might get thousands and thousands of offers just from one airline for one request. We're just looping over this Ecto data structure over and over. It's been fun on the data side.


Actually, at the more fundamental level, one of the other advantage of using Elixir is that Duffel can be visualized as a big pipeline, where we get data in, transform it all the way to sending a request to the airlines, we get data back, transform it into the Duffel format and then send it back to the API consumer then. I wish the code base was that simple, that what I just explained, but theoretically, it should be quite beautiful.


[00:22:10] JE: Can you talk a little bit more about the conversations in your team at the genesis of this looked like? I mean, were you working on this alone? Did you have to persuade some friends who are either in the Elixir community, or elsewhere to come work with you in Elixir? What was the very beginning in the engineering room like?


[00:22:29] SD: Yeah. I started this company with two co-founders. One of them was Tom, who is with the company now. He's a product designer. Also, one of these rare breed of product designers that can also code very well. And he's probably equally good developer than he's a product designer. Fortunately for me, because he was going to focus on all of the front-end side of the house, I didn't have to do too much convincing, especially in the early stages. It's just like, well, we're just building a first version and we'll see if we need to rewrite it. It's just a prototype. We rewrite it. Here we are three years later, everything's still built on Elixir. It wasn't too difficult to convince him at the beginning.


[00:23:16] SM: When you're hiring new team members, are you — I guess, how do you go about finding Elixir talent?


[00:23:22] SD: We don't look specifically for Elixir talents. We hire developers that have experience with other languages and we train them on Elixir. Yeah, I think there's a lot of improvements we could do on that training process. It has worked fairly well for us. I’m actually quite a big believer in hiring software engineers that are not necessarily restricted to one language and are happy to explore.


Obviously, they need to have an appetite to do Elixir. We're very upfront about that in the interview process. The last thing you want as a developer is coming into a new job and realizing that you're using that language that you had no idea it existed. That's the strategy we followed so far and I think it worked quite well for us.


[00:24:07] JE: Do you know if you have any clients who are using Elixir to ingest your API?


[00:24:13] SD: Yeah. Actually, I know of one, at least. We're working with this online travel agency in France called Ulysses. Very small team, growing super rapidly. At some point during their life transition from, I wanted to say, JavaScript to Elixir, and now the old back-end is written in Elixir.


[00:24:33] JE: It's called Ulysses?


[00:24:35] SD: Yeah.


[00:24:35] JE: That's a great name. That's a great name for a travel agency. That's so good.


[00:24:40] SM: Is your main client travel agents, or are your main clients travel agencies, or are they other startups like you? What's your main client pool look like?


[00:24:50] SD: Yeah. A bunch of startups that might happen to be travel agencies on the leisure side, so online travel agencies, small and medium-sized online travel agencies. Also, corporate booking tools — yeah, it’s fairly distributed in the world. Also, the use cases are quite varied.


[00:25:11] SM: You said you're working with about 20 or so airlines now. What does that process look like if you're onboarding a new airline, if you're expanding?


[00:25:20] SD: Yeah, we spend a lot of time on the, I guess, selling side and convincing them that they should work with Duffel. Once we've agreed, once they've agreed to work with us, then we get access to their sandbox reservation system and we build an integration. Then once the integration is ready, we go to production, do a long testing phase, where there's just quite a lot of back and forth and calls and certifications and whatnot. And then we go to production. Yeah. I mean, it can take a few months. Sometimes can be a bit quicker. Sometimes can be a lot longer.


[00:26:01] JE: Do you have any horror stories from trying to integrate with any airlines that you could mention? I just imagine that there's one or two airlines that are particularly embarrassing. Maybe you can't name them, maybe you can. I don't know. I figured I’d ask.


[00:26:15] SD: I mean, not with one airline in particular. I definitely wouldn't name them if that was the case. We've seen a lot of our stuff. With that example I gave on documentation earlier on, the fact that we received documentation for endpoints spread over many, many Word documents and many, many pages inside this document, that's definitely not fun.


We have this one IT provider as well that has — the airlines are using IT providers that provide some of their systems sometimes, or external consultants. One of them has built an API for an airline and they have this error page, the list of errors, which probably accumulated all of the errors code that you can get since 1965 or something. You can scroll through it for probably five minutes at normal speed. It's just errors, like error codes, error codes. You just scroll and scroll and scroll and you never get to the bottom of it. I mean, we could do a whole show on horror stories with airlines.


[00:27:25] JE: I feel like, if you've got the time, we should just do it. Yeah.


[00:27:30] SM: I obviously really want to have that conversation. I’m such a travel nerd when it comes to the tech behind travel. Oh, spin off.


[00:27:38] SD: One thing that's quite interesting that's happening now and I won't mention the airline. Actually, it's many airlines. We will search API, receive results that our customers asked. They’re browsing, maybe on U-list, for instance. They are looking for flights. Then we receive offers from the airlines, send them back to the client. The client chooses one of these offers and we have to do a price confirmation call with the airlines and say, “Hey, the client selected this offer. Is everything okay? Is it still available? Everything all right with this one?” They also, they are supposed to send us more information about that offer. The baggage allowance and all of the conditions and that are attached to it and a bunch of other things.


One of the things they can also do is adjust the price, if the price is incorrect. We have many, many, many occurrences with a set of airlines where that price will change significantly. $150, $200 above what was quoted initially. But also, it will happen in the other direction, where they will buy a flight that actually — they would charge us less for it, so they're losing money. And sometimes, a lot of money on every flight.


We've had calls, we've surfaced that bug, which we consider as a bug. The response from the airlines is, “No, it's working as it's been designed.” For them, it's not a problem. I’m like, “No, it is a problem.” They know why it's happening. They can't fix it. That is all outside.


[00:29:17] SM: That's amazing.


[00:29:20] SD: Yeah. Scary.


[00:29:23] JE: I want to ask you a little bit about what the next phase is for y’all at Duffel. I’m curious, how big is the team? Are you growing? Are you getting into new products? Are you expanding in new technologies? Are you going to be an Elixir company for the foreseeable future? Our audience is mostly Elixir developers, or Elixir curious developers. Just tell us about where Duffel is heading in the next, let's say, year or so.


[00:29:48] SD: Yeah. I mean, to your last question, I think Elixir is going to be here for a little while. I mean, it's the core of our stack now. It’s the core of the API. We've built the application using umbrella applications. Yeah, everything is Elixir, Elixir. It's not services that we can suddenly move around.


The team has grown quite a lot in the last year. We went from 14 people to 40. That's been super interesting. Next year, the same thing is likely to happen. Now, we will at least double the team. We might expand into other products. I think there are other verticals of travel that are very interesting. I don't want to comment on it too much now, but there's definitely more on the horizon for us. We've got so much to do with flights, that I don't see us doing any announcement in the near future. Where I stay tuned. More and more to come.


[00:30:43] SM: We'll have to do a part two to hear more about that.


[00:30:45] JE: I do want to ask one other Elixir related question. Sundi, maybe you have more, but I’m curious if there are any ways that Elixir has really enabled you in ways that you might not have been enabled if you had been working on a platform like Rails. Or I’m, not even sure what else you would use in the travel space, Closure maybe.


[00:31:02] SM: JavaScript.


[00:31:03] JE: JavaScript.


[00:31:08] SD: Yeah. I mean, I’m a fan of Elixir, but I’m also a, I guess, pragmatic technologist. I think we could have done what we've done with Duffel with other languages and probably as well. One thing that it enabled, at least for me initially, and maybe if I were to bring the team on the show, they would have a different opinion. It was just fun to build it. We didn't have to worry about some of the things that we would have to worry about with Rails. For instance, GoCardless, the previous company I was working at was all built in Rails.


There's always concerns around scalability and how do you distribute workload, which is always solvable. But I’ll just come baked in with Elixir. You just don't have to worry about it. You know the platform. It is going to scale for a little while. You're not going to run into hard limits early on. Yeah, I don't know if I totally answered your question.


[00:32:07] JE: Well, I think another way to frame it would be if you knew about developers who might be working more at established companies, that are looking to get Elixir adopted into their companies, what advice would you give them in terms of selling Elixir to stakeholders in the company?


[00:32:24] SD: I would say, pick a problem that you think Elixir is going to — where Elixir is going to show its strength. Anything where there is a lot of concurrency and you need to span out, or handle data coming from multiple streams. I think Elixir can really shine there. Recently, I would say as well, I’ve been playing a lot with LiveView, so Phoenix LiveView. I think LiveView has a lot going for it. For any web app, or anything, I don't know, like internal admin tool where you don't necessarily have two separate teams, like when one JavaScript and one back-end that can work on the tool. You can do a lot with LiveView very quickly and I’ve been super impressed with the framework. Yeah, that would be my two recommendations, I think.


[00:33:15] SM: What are you using for your front-end now?


[00:33:17] SD: We're using Next.js. All the dashboards are built with Next.js. Well, remember what I said about having a brilliant co-founder that does JavaScript and he's also a product designer. I brought Elixir into the company and he brought Next.js, so fair game.


[00:33:35] SM: Yeah. It'll be interesting to see if you get to integrate with LiveView moving into the future. We've definitely been keeping an eye out to see more examples of people using LiveView in production. Definitely keep us posted.


[00:33:45] SD: We do in some ways. I sneakily introduced LiveView for an admin tool that we have, so the back office for Duffel. Well, I say sneakily and there were reasons behind it. Also, I think he was sneakily, if I’m honest. Yeah, it's been working quite well for us. People are not necessarily accustomed to the way of working with LiveView, so it's not without friction. I think it's showing promises.


[00:34:16] JE: Before we close out here and we'll give you time to plug anything you want. I’m curious about the London Elixir Meetup, because that's actually how I found you is through the London Elixir Meetup. You're listed as a co-organizer. Obviously, meetups are not happening right now, or maybe they are, in which case, you should tell us about them because that's awesome. I’m curious, what's the status of the London Elixir Meetup and what are your plans for it?


[00:34:45] SD: Yeah. I actually need to give a big shout out to Baris, who's been in charge and running things on the meetup recently. Duffel has taken a lot of my time. There haven't been any events recently. I think we hosted a few at the Duffel office, actually, before the pandemic. I’m looking forward for that to resume, hopefully in the new year. Otherwise, no major plans.


[00:35:11] SM: Yeah. I can definitely speak from a meetup organizer standpoint, that it's been tough. It's not even just moving to virtual meetups is one thing, but the exhaustion rate that people have, the screen fatigue, Zoom fatigue from just being in meetings all day and then wanting to go to another one. Meetups used to be hanging out at the end of the day, not another screen meeting, or another call. It's been rough.


[00:35:37] SD: Yeah. A lot of it is also, I think the presentation part, you can do fairly easily on Zoom, but that's not the most interesting part of the meetup. The mingling and eating pizza and all of that. That's the real fun and talking to other Elixir developers and that's much harder to reproduce.


[00:35:54] JE: Do you think we're going to get a directory of underground meetups, like speakeasies and places where people are low-key, getting together to whisper and hushed tones over beers and hide from the authorities? Anyway, that's a stupid fantasy. We want to give you the final few moments of the episode to plug anything you want, ask the audience for anything you want, tell them where to find you, how to find Duffel, how to get involved with Duffel. The floor is yours.


[00:36:25] SD: Well, thank you. Yeah, I think I would have two requests for the audience. One is we are hiring for Elixir developers. Not only Elixir developers, but if you happen to know Elixir, it's definitely a big bonus. Team is based in London. Yeah, we'd love to hear from you if you're looking for a new job.


The second thing is for all the developers in the audience, which hopefully, should be maybe all of you, just head to duffel.com, sign up. If you have any feedback on the onboarding process, the documentation, we're always looking to hear from developers, so I would love to get your feedback.


[00:37:00] JE: Thank you very much, Steve. That's it for this episode of Elixir Wizards. Thank you again to our guest, Steve Domin. And my co-host, Sundi Myint and my producer, Eric Oestrich. Once again, I am Justus Eapen.


Elixir Wizards is a SmartLogic podcast. Here at SmartLogic, we're always looking to take on new projects building web apps in Elixir, Rails and React infrastructure projects using Kubernetes and mobile apps using React Native. We'd love to hear from you if you have a project we could help you with.


Don't forget to like and subscribe on your favorite podcast player. You can also find us on Instagram and Twitter and Facebook, so add us on all of those. You can find me personally at @JustusEapen and Eric at @EricOestrich and Sundi at @SundiKhin. Join us again next week on Elixir Wizards for more adopting Elixir.


[END]




        © 2020 Elixir Wizards