Francesco Cesarini is the Founder & Technical Director at Erlang Solutions. It is a global corporation with a focus on soft real-time systems with high availability and scalability demands. He joins the show to share his inspiring story of how he was able to establish and run his own company. He begins by discussing how he came to be successful over the years and his road to getting there. 

Hey everybody and welcome to another episode of Elixir Mix and this week on the panel we have Alan Weimar.

 

new.

 

Adi Ayingar

 

Hello!

 

and me, Sascha Wolff and we have a special guest and we actually had a technical difficulty so I forgot how to pronounce her name Francesco Cesarini I think it was so Francesco,

 

Spot

 

why don't you tell

 

on Sasha, spot on.

 

okay so yeah Francesco, why don't you tell everybody who you are and what we are probably going to talk about today

 

Hi, so I'm Francesco. I'm the founder and technical director of Erlang Solutions. I've been working with the Erlang ecosystem for the last, I'd say, 25 years, probably even longer. It's 28 years now. And I started as an intern at the computer science lab with the inventors of Erlang. I worked on the team which released the first version of OTP, so the R1 release of OTP, back in 1996. I co-offered two of the O'Reilly titles. Erlang programming and designing for scalability with Erlang OTP. And yeah, I, yeah, I'm responsible for delivery at Erlang solutions these days, uh, help a lot with kind of recruitment and overseeing the various projects. And in my spare time, I teach at Oxford university at a concurrency oriented programming course.

 

Nice, that is quite the CV you got there, Francesca. Hahaha.

 

It's a challenge when you try to drop it down to one page, but yeah, it's doable.

 

I think for me it would be interesting to hear how did you end up getting into all of this? What's your story there? Where did you start off beginning this impressive journey?

 

So it was in university. I think at the time it was called, this was before concurrency, I think, concurrency rented programming, the term was coined in 2002, but in 1994 the lecturer came in and he pulled out the first version of concurrent programming in airline. which he kind of waved to the class, said, this is the book, read it. He waved some exercises, you know, do them. And, um, and then off he went and started lecturing about the horrors of parallel programming and doing the exercises. We never, I, I, you know, none of those horrors he was describing actually materialize. You know, he was talking about deadlocks, trace conditions, mutex is your corrupt memory. But, you know, we were using airline for a simulation, uh, where we had wolves roaming a virtual world we had and they were hunting rabbits. These rabbits were hunting carrots. And if a wolf saw a rabbit, it broadcasted to other wolves within a certain radius and they'd start chasing the rabbit. And the rabbit would cry wolf to, to, to other rabbits within a certain radius. And the same applied to if a rabbit, you know, found a carrot patch, Hey, there's food here. And if wolves didn't eat enough rabbits, they'd run out of energy and die. If wolves ate a lot of rabbits, they'd get fat and split in two. Uh, and, and the same applies to rabbits. If the rabbits

 

That's

 

ate

 

how

 

a

 

it

 

lot

 

works.

 

of very, very, very piece of the year. And if a rabbit ate a lot of carrots, uh, Sanergy would go up and it would split into, into two rabbits and, uh, the goal was to create a balanced world. And it was great. You know, I mean, our language was one of the many languages here we got introduced to. But until a few months later, when we had to do exactly the same exercise in AFEL. And the airline exercise had taken me about 40 hours to complete. The AFEL version, AFEL is an object-oriented programming language invented by Bertrand Mayer, which used some very interesting concepts around preconditions and contracts, basically. But it was being pitched as a language of simulations. And despite that, it ended up despite that, and despite the fact that they tried something very novel at the time, which was called pair programming. So they paired us up and two of us work together on the solution. Despite having already solved the solution and reusing a lot of the ideas. It ended up taking two of us 60 hours to solve exactly the same problem. So three times to original time. And at that point, that's when it kind of tweaks saying, well, do we tweak on two things? using the right tool for the job, I think

 

Mm-hmm.

 

is critical. And the right tool at hand is usually not, it's not necessarily the tool which is being pitched as the right tool for the job. And second, you know, I think there are a lot of features in airline, which made me realize that, you know, which made me realize, you know, that this is the future. It might not be airline, but I think it's going to be a lot of, it's going to be, they're going to, they're going to be a lot of. ideas and concepts which will be taken from airline and put into future programming languages. So this is where I picked up the phone, I called Joe Armstrong, the co-inventor of airline at the time no one knew who was with Ayrton Switch put me through to him. And we clicked two weeks later, I was out for an interview and got the internship. So this is how it all started.

 

That's really cool. I just especially imagine you're just picking up a phone and calling Joe. Different times than I guess.

 

He's always been approachable and you go out and find emails. He's always answered people emails. He's always helped and he's always taken the time. So it was no different then than what it was until a few years ago, until he passed away.

 

I mean, me myself, I came so late into the Beam community that I only saw Joe once on the code beam in Stockholm, and it was already at that point, like, oh my God, that's Joe Armstrong. So, yeah, like I said, different times, I guess, at least for me.

 

It was interesting walking with him around the streets of San Francisco or going to museums with him, people would recognize, they'd come up to him, oh, you're Joe Armstrong, you know, and they'd recognize him, which is something I don't think he ever, he liked, enjoyed, but never really got used to, you know, because he was never expecting anything like that.

 

Before we hit the record button, you kind of hinted at your company that you kind of grew quite a lot over the pandemic. And I think for a lot of people working in like Rufa Beam, Elixir, Erlang, whatever, right? Building a company or like being involved in building a company is something they don't have a lot of experience with. So... Maybe you can give a bit of like inside, like how you ended up being there, right? And what, what, what you kind of like, how you build, bridge this gap between like having this technical background, but still being involved in all of this, the business side of things, you know?

 

It's a really good question, Sasha. And it's not the first time I've been asked that question. I mean, I have a master's in computer science. I know nothing about running a company. Uh, but there was one thing which I built a company around, which is the passion. And it's a passion for airline, which eventually became the passion for the whole airline ecosystem, which includes the beam. It includes Alex here. It includes LFE and, and probably 35 other languages, which are today running on the beam, I think of which probably five or six are being used in production. But what ended up happening was after probably four or five years of having lived, having worked for Ericsson in Stockholm, kind of felt it's time to move on. It's time not move on job wise, but move on country wise. And I've been for a long time looking for new opportunities abroad. And I had an opportunity to move to London. Didn't have a job, but at the time you had the freedom of movement so you could easily move. amongst countries. And my thought was, let's move to London, take some time off. I'd never taken any time off between university and work. And so I basically moved to London and started looking for a place to live. And within two days of having moved to London, Mike's girlfriend was getting calls, voicemails, saying, hey, You know, we're looking for Francesco. Um,

 

Wow.

 

can you please call us? And it was basically the first customer who had heard I'd left Ericsson and was looking for help with Rounder Erlang. And within two weeks, uh, within three weeks, I had three customers, um, who needed, who needed, um, consultancy services and a permanent job offer. And this was at the time where you could count the users of Erlang on on, you know, on the fingers of both hands, you know, so

 

Mm-hmm.

 

there were maybe 10 commercial users of Erlang. The year was in 1999. It was a year after it had been released as open source. So this is how it happened. And we kept on kind of, we kept on expanding. So well, apart from a deity crash, which happened in 2000, 2001. So the dot com bubble. 2003 ended up hitting the ground running, got into T-Mobile and started working with them. I got customers in South Africa. I got customers, you know, got multiple Ericsson customers, started taking on subcontractors. 2004 started taking on interns. And 2005, a business partner who had the business side, knew the business side of things, came on board. We started taking on permanent employees and have kept on expanding ever since. And I think there's a trifle group which owns a good part of Erlang Solutions and they've got a very kind of good solid approach to managing companies where they basically give the different business units a lot of independence, which means... From one side, it means you're learning from your mistakes. But on the other hand, it means doing what you're really passionate about.

 

Mm-hmm.

 

And the whole goal is trying to keep, you know, the different officer units small, you know, between 15 to 25 employees, because that's where you're just, you kind of, the culture grows and the staff retention is at its best. And... pretty much this is what we've done during the pandemic. We've doubled in size during the pandemic and there are quite a few contributing factors to it. But one of them is that we work with infrastructure. So we're usually down some heroes. We're the ones who get yelled at when things go wrong and don't work, but which no one talks about when, which no one talks about when. When things go well. So, you know, it's not so much, you know, we don't do that much around UI user interface and user experience, but we do most of the backend system. So anything from your kind of rabbit MQ, you know, MQTT, um, to, you know, to, to, you know, proper kind of microservices backend architectures and your payment systems, you know, so when the whole world went online, uh, in, in 2020, these and started doing all of the shopping online, those were the systems which were under strain, and those were the systems we used and worked with. So, a lot of work started coming in. The second thing which happened, and that happened actually in August of 2020, we made the conscious decision of becoming, continuing becoming, being a remote company, even after the pandemic. Prior to that year, we had offices in London, in Stockholm, Budapest, and Krakow. Whilst, you know, we also had an America's team who was fully remote and had been fully remote, uh, you know, for quite a while. And we took all of the lessons learned of running a remote team in the Americas. And this was a team year spread across, uh, North central and South America and applied them to the rest of the company. And the management team set in and took the decision, you know, You know, the question asked was after the pandemic, when things get back to a new normal, do we still want to work, you know, keep on being remote or do we want to, you know, go back to the offices? And it was pretty much a unanimous vote among all of the business unit leads, which was, let's stay remote. And that's when we started drawing up guidelines and basically for this shift and we still have offices in these cities, but there are a fraction of the size of what they used to be. And what this has done is it has increased the talent pool drastically. We already knew that from running the America's team, which is I think the most successful unit right now, which has expanded the fastest, but with... with the largest staff retention. And so we knew that, but it's the biggest challenges kind of changing people's mindsets and approaches. And so we went in, we got all of the lessons learned from that team and we put in place guidelines which are different business unit leads were then allowed to decide on what to pick and choose from. And it was basically a collection of experiences which we did. So... Not only that, but you know what this also another thing which was happening was that we were noticing that we're employing a lot more women during the pandemic and it was really helping with the diversity and not quite thinking of what it was but then quickly came to realize that it was all had to do with remote working. We've kind of delivered balance and the quality of life remote working brings to us. And that applied not only to kind of a diverse group of engineers, but it, you know, so ethnically diverse, you know, diversity in terms of where people actually live and also gender diversity, but also talent diversity. So there's so much talent, which, which, you know, the remote working opened up to, which helped us recruit. Our biggest challenge to growing was recruitment and finding the right people, the right mindset. So that worked. And then there's one third thing which happened, which was of those who really kind of embraced the pandemic and realized that working from home was something great, was a CEO. And he decided to find, he was commuting. twice a week, three hour commute in each direction. And it was insane, absolutely insane. And he felt it's time for me to step down, manage to bring the company to where it is. He'd done a fantastic job, his name was Stuart Whitfield, but he'd managed to get a job closer to home with a much smaller company, which would allow him to be closer to his family and not have to travel as much. And together with Gere Larsson, who's the head of Triford, he said, Okay, let's replace one CEO with seven CEOs. And every business unit had basically got given independence and the responsibility it took, it took a while. Uh, it took a while, but they got given, um, free reigns, you know, to, to take on, uh, and much less top steering to, to, to take on and start building, uh, the different business units and start expanding them. And that has had amazing impact. on staff retention, but also on growing and expanding. And as you say, you're doubling in size. Yeah, I mean, for a company to go from five employees to 10 employees is really easy. From 10 to 20 is also easy. From 20 to 40 becomes harder. And what we learned is going from 40 to 80 was really, really hard. And what happened during the pandemic is we went from around 100 to 200. I think we hit, including subcontractors, we passed a 200 mark last year. And this is, this is employees and subcontractors. But if you give people independence, you're going from, going from 10 people to 20 people is easy. And that's what most business units did. And that's how we managed to double in size. Yeah, we spun off. Two new business units as a result. The London team became the London Dolphins. We spun them off from head office and the RabbitMQ team, which is another team which is doing really, really well, which is focusing on basically not just RabbitMQ, but messaging in general. So yeah, so this is what happened during the pandemic. So I mean, people say there are a lot of negative things which happened indeed, but I think what I keep on saying is embrace the positives, embrace the things which, which, you know, which will stay with us, the good things which will live us even after. And, you know, I can describe the, since the scenario when I, we, I was on the management call when we took the decision to remain, to remain, to remain distributed even after the pandemic and remote, allow remote work after the pandemic. And I was by the beach on the lake, the largest lake in central. I just picked up my children. from summer camp, that daily summer camp. And so, yeah, I think, Junip and I, everyone who's started with childcare, but we managed to get them into a camp. And they were playing in a playground. I was under a tree in the shadow on my phone on this management call. This is where I took that call, and that's where we all jointly took the decision. And I think it's that quality of life, which has, yeah, I think impacted everyone so much, allowing them to keep on doing what they do best. And one final thing, and then I promise you I'll let you take over, is the fact that our customers realize that we, you know, we are just as capable of delivering remotely as, as we are delivering in person and, you know, customers being Oxford University who are allowed, you know, we're very against the remote courses. Uh, it took them a while to get used to it. You know, they're allowing it. Um, uh, customers, but not just when it comes to training, but also when it comes to building systems and delivering systems. If you've got the communication in place, you've got the infrastructure in place, they realize that you can be as productive or more productive that way. I mean, from my end, the pandemic allowed me to do much more of what I love doing, which is teaching. Previously, I maybe had the bandwidth to teach two courses and one or two tutorials a year. This went up to four or five courses a year and four or five to six tutorials, which I can only do remotely because traveling was taking just too much time and being away from the family was not working for me. So this is what happened and it's just been an amazing experience and a side effect, staff retention has been really, really high. We've never seen such high numbers in the history of the company.

 

And just to say, Francesco, I think everybody enjoys you talking so long. At least I did. So no worries about that. Wow. First of all, thank you for sharing this and giving that insight. There are a few things I would like to be asking, but I also want to also cause Adi and Ellen, if you have any questions, just jump right in. Like one thing I found very interesting where you just said that the customers, when customers realized that. you working remotely work just as well, or maybe not even better as before. Is this something where you've also observed like an impact on their culture? Because I definitely, I think we've seen, especially in our industry, how the pandemic kinda supercharged the whole movement towards remote work, let's say that. But there are still industries out there which are hesitant to move into that direction. So I'm wondering if basically... Rolling Solutions, your company being like a picture book example of how it can work. If that has had an awesome positive impact for some of your customers, maybe embracing this model of work more. Does this question make sense?

 

It does. And I don't know if I have an answer because every every company is different. Every person is different. And indeed, you know, I think a lot of and not only every office, every business unit we have is different. So it's really hard to answer. But I mean, from our end, initially, I mean, they were forced to, you know, to embrace this way of working.

 

Mm-hmm.

 

And in many cases, yeah, we actually went in and helped them. helped them understand how they could do it. Because we had experience, at least from the America's team, we had a lot of experience in doing so. And it's very simple, you know, I mean, very simple rules of putting in place the communication, making sure that the face-to-face meetings happen. And, and then you're making sure that you can show that you are productive. and that you're available and productive when you need to be there. So, you know, it's, we, I'd like to hope we have helped customers. We're struggling in that transition. Um, but, you know, I think, you know, every company, every business unit we have, we're narrowing solutions is different and, and we really kind of value the culture

 

Mm-hmm.

 

and respect the way they want to do things. And as an example, uh, Budapest and Stockholm have one day a week where they work from the office. Other offices have in other offices, you sign in and say you want to go in and work remotely. I know from me at my end, I ended up leaving London after 20 over 20 years and moved to Rome. And now you know, I and I fly into the different offices and meet people work work there, you know, for a couple of days each month. You know, to interact with people. So yeah, but the rest of the time, yeah, I'm working from Rome. I'm working remotely now.

 

Yeah, but if you have so many people working remotely, do you, you don't fly to their homes and knock on their door and say, I'm here to work with you for the afternoon or something like that, right?

 

It has happened. It has happened. Where, you know, I happen to be driving across Europe or staying somewhere, knowing that an employee is a 20 minute drive away. Hey, do you want to do your work, you know, together? Oh, yeah, sure. And we so we've done it. Or we've just met for lunch. So yeah, and this is very, very important. not only I think company get togethers or kind of business unit get togethers and project get togethers are just as important. People need to meet in person and they need to interact and get to know each other on a personal level which is you know kind of goes beyond you know beyond your meeting on zoom and socializing on you know virtually and for that yeah we have your project get togethers where the project meets regularly in person. We have your business units meet meet at least three, four times a year where everyone within that organization goes in and meets together. And we've got conferences. We run all the Codebeam and Elixir Conf EU conferences. And that's another opportunity which all our staff take to go in and not only meet the community, meet the speakers and meet their friends, but also meet their colleagues and get to know them better.

 

Yeah, I can also definitely plus one, do plus one on that. Where since I've been working remotely for like quite a while, basically was that beginning of a pandemic. Just by the nature of my previous employer, which was very medical focused. So we were immediately like, okay, everybody works from home now. Um, that it's like the number one thing I sometimes feel I'm missing and that also colleagues are missing, like actually meeting people in person. Like just these, these, these coffee machine chats. which tend to happen or like you go out for lunch and just, and maybe sometimes talk about work, but sometimes also not just sometimes talk about life. And from my experience, that's also the hardest thing to reproduce to a certain degree, like having this kind of informal check-ins and also getting to know the people behind the work.

 

especially the new joiners

 

Yeah.

 

who weren't there before the pandemic. And we tried to, so we, we tried to cater with that to some degree with kind of virtual get-togethers. So, you know, every, you know, we've got tech talks, different offices have their own internal tech talks, but then company-wide, you know, we've got the dojos every Friday, we've got virtual coffees, so, and everyone from any office is welcome to join any other offices virtual. So people will pop in and you'll meet colleagues from other countries. We've got employees who go in and work from other offices. So you're the kind of digital nomads who will go in and work from Krakow or from Stockholm or London office as when they feel like it as well. So, but I agree with you. I mean, it's, you know, indeed in America we call it the water cooler chat. the virtual

 

Yeah,

 

meeting,

 

yeah, exactly.

 

because that's what it is. And you can talk about anything except for work. Yeah, that's the rule, at least for the Americas team.

 

actually still a little baffled by the numbers. As you were talking, Francesco, I was just looking up crunch-based numbers for Erlang solutions. And it's pretty crazy that you were able to hit this kind of revenue while just being in such a specific tech. I don't think I know of any other consultancy who has hit that. And as an aspiring entrepreneur who wants to eventually work and ideally looks at least like Beam, I'm trying to see, there must be a lot of reasons why you hit that. And you gave a lot of that initial part of the story. I would love to, if you would give some strategic choices you made later on that allowed you to do this. I see that you got acquired by Trifork, who also looks like some of the other, like, who-me-ow I see here, bash-o. So, like, maybe how did that acquisition help you get there? I would love to get some more insights over there.

 

So going back to what you were saying, I think when we were around 25 and aspiring to become 50, so I mean, the aspiration was I actually stopped counting employees, by the way, when I couldn't fit them on the fingers of my hand. So beyond 10, I stopped keeping track on how many we were, because I think it was just a number at the end of the day. What was important? But. But when we were around 25, one of my employees told me, oh, you're too large for a kind of niche consultancy company. 15 is the right number, and you shouldn't grow beyond that, because you won't be able to grow beyond that. And I think it's, and it was, my answer was, why not? There's not enough business. Well, prove

 

Hehehe

 

me wrong. And what brought us to where we are today is, you know, is passion. It's a passion for what we do. It's the belief that we're working with a superior technology, which for certain problems is the right tool for the job. And yeah, I think we've done a lot of mistakes along the way, but I think a lot of these mistakes have been addressed and fixed. Uh, you know, I think one of my favorite examples, which I always give, which, uh, was fixed graciously by Jose Valin was, you know, for example, trying to get Erlang into the web development space. And we were doing it with our computer science hats on, you know, we had, you know, back in early 2000, we had the fastest web servers, yours, uh, yet another web, so which is still out there. and still being used in anger was probably three or four times more performant and more reliable than Apache. You know, we have the benchmarks for it back then where Apache couldn't go beyond 8,000 simultaneous TCP-IP connections. Yours was handling 70, 80,000 with a sustained throughput until you hit memory limits on the beam. And we noticed today, you're back then, they didn't believe us. Uh, you know, and we gave the numbers. We didn't believe, you know, they still wouldn't believe us. And we were trying to push, you know, air, like in the web space, but we were doing it with our computer science heads on and, you know, where I really love you, what Jose Balin has done is he put his web developer hat on and you said around to, to, to creating Alex here, you know, but the purpose of, of inventing Alex, if you ask him was. I wanted to bring the power of Erlang to other communities. And so understanding how these other communities think and reason, he created a programming language, which would be, you know, which which had the frameworks needed for web development, had the tools needed for web development. People kept saying, oh, Erlang tools are are rusty. Yes, they are rusty if you want to do web development. And if if you're coming in, with a certain level of skill sets. They weren't rusty for what the problems we were solving, which were problems within the enterprise where your enterprise can be a little dictated. You need to use this tool, this tool and that tool. So there's no point in using, you know, having mix and hex when we basically got told you can't use them and you can't use them because you need to use what we tell you to use. And so, you know, I think, you know, the word I'm looking for is approachable. He made airline approachable. to initially a wide set of community, to the huge community of web developers who didn't have and didn't want to have a computer science degree because those were not the skills you need when you're doing web development. You need to have user empathy, user design, user experience, and know how to design user interfaces. And we in the airline community didn't know how to design a user interface if our life depended on it.

 

Hahaha

 

And I think in many cases that's still the case, but... That's where I keep on saying, the airline community and the electrician community have a lot to learn from each other. And together, you're just stronger because it's different use cases where different technologies are being used. And then from, you know, from, you know, from, you know, web, you know, I think a lot of great work in the embedded space with nerves.

 

Мм.

 

And I think in the embedded space, I think we understood embedded developers fought and reasoned. And that is the reason why I think airline never got, well, airline was being used in embedded for telecoms and telecoms is embedded, is embedded, it's all about embedded. So it was being used there on a large scale. But when processes started getting much more powerful, when Raspberry Pi's came along, you know, we struggled to get it to become the language of choice because, you know, people still have. because of the mindset in the embedded community, in the hardcore embedded community, where they won't really move away from C, because they're still thinking in terms of hardware constraints. Not realizing that hardware constraints aren't an issue anymore, and that we're working on multi-core architectures. And not only multi-core architectures, but architectures with a wide diversity, different set of cores. And we saw that. Yeah. And that was even visible when the parallel board came about. You could have a 64 core co-processor on the parallel board about six, seven years ago and people went in on Kickstarter, they funded it. And then they got the board at home and says, Oh, this is great. What do I do with it now? How do I program it? And, and, and, and so, you know, that never really took off, even though, you know, it was an amazing piece of piece of hardware technology. And so, you know, so for embedded, I think, you know, I think the challenge there was not so much, you know, was not so much, you know, that we were saying the right, the wrong things, we're saying the right things, but that the mindset was very, very kind of narrow. And I think, you know, and you ask Frank, you know, what his major challenges are, and he'll tell you the same, he'll tell you exactly the same. You know, but I think good news is I think a lot of the work we did back then, you know, it was used by Frank in nerves. So we had a project called airline embedded and he took that project and then he built an Alexia wrapper around it and eventually we wrote it to Alexia. So, um, that, that was, you know, that, that was good. Yeah. And it's good to see that work you're living on it. And now, yeah, machine learning again, it's another area, which, uh, I think. we'll be hearing a lot about, which makes me really, really excited. What makes me even more excited, I think, is the intersection between machine learning and embedded where, you know, we'll be able to deploy, I think, a lot of the machine learning, um, uh, algorithms and instances on the edge and on the devices themselves. Yeah, I don't know if I answered the question or went off in a tangent, but the answer is passion. You need to be passionate about what you do and everything else will follow.

 

and everything else will follow. Awesome. And like you mentioned, Elixir's inception was also the right time, and that helped you as well. Did the acquisition help at all, or did that change the dynamics? In what ways did that change?

 

No, it didn't. It didn't. I don't think it changed the dynamics other than because Trifork expands by letting companies get on with it. They go in, they acquire companies, let them get on with it. And not really, you know, they have a lot of experience and there's a lot of experiences exchanged among business unit leaders. But It's, uh, but you're going in and, you know, top steering 63 companies, as is the case right now with the CEO of Triforce is impossible and it will never work. Uh, it would never work because you can't do that. It's just too much. So by finding the right people to run these companies or helping grow the right people is their approach. And I think that's the best contribution which, uh, which they've made. Uh, as I said earlier, replacing one CEO. with seven rates, with seven, right now seven CEOs. That is, you know, and

 

Awesome.

 

helping these seven people grow and take the responsibility. I think that's really been one of the best contributions, which I would have never thought of myself. Which I recommend anyone, you know, anyone to do. You know, give them independence and let them, you know, learn from their own mistakes and grow themselves because that will also mean they'll take responsibility.

 

Does that make sense?

 

Yeah, I did want to kind of come back to this. It's actually kind of interesting to hear that you, the, I don't know if it's necessarily you, but you know, what you guys are working on with the web development, right, how you approach this from two different angles and saw which one actually worked. You came in and said, okay, you know, we have the fastest, we have the best piece of technology out here. We worked really hard on this, it works great. Well, here's the stats, but that didn't matter, right? What year was that? Because I'm kind of curious about what year that was. Do you know?

 

A search the Apache versus yours blog post Joe Armstrong wrote, where what he did is he went in and got benchmarks on a dual core machine for Apache and yours. And there's a huge thread on the mailing list, a lot of debates around it. And in some case, it was pretty hard to reproduce. Joe Armstrong was very much of an innovator, but he wasn't very scientific, scientific or precise in how he did things. So, um, some people, you know, failed at kind of reproducing these and, and, you know, we're more loud about their failures than, uh, you know, instead of trying to get it right. And, um, so it was around 2002. Uh, we were working on the airline web in 2007, 2008, probably. And, um, and, and what airline web did was we had what we call the limestack, the Linux, uh, the yours web server, uh, the Mnesia database. and Erlang where Erlang was the glue. And the reason we were the fastest is that we had everything running in the same memory space. The web server would receive the HTTP request. So yeah, the expensive part was parsing the HTTP request, which again, it's a small string, it's not that expensive. We had the concurrency, which would allow us to have hundreds of thousands of requests being managed at the time. I think, um, on, on a dual core machine. Well, this was before multi-core, but on a high range desktop, you could probably get around 80,000 TCP IP connections, 80,000 to 100,000 TCP IP connections. So we could have 100,000 users managing it. And in parallel with that, everything was running in the same memory space. So you get your HTTP request. There was no IO. to databases, there was no IO to go in and, you know, to, to, to you with your scripts. So it was all Erlang. So it would take microseconds to look up database data in Amnesia and do everything to get and send back the responses. So actually, you know, generating dynamic web pages every time, you know, you had a request was cheaper than serving static ones.

 

Yeah, that definitely makes sense. But what I think was interesting is that raw benchmarks are cool and interesting. And of course, the work you guys put in there is super useful. And I wish I heard about Lime Stack up before. But coming back to this whole thing, I think people have come to the stage where it's like, well, what's easier? I think, like you said, Elixir came in. They brought in a lot of easy to use developer tools compared to what you guys had. What you had was raw, like engineering, OK, this thing could really run, but you had to get up to speed with all that. Whereas Elixir, that kind of made things easier. Right. And it's I think that kind of made you guys

 

The correct?

 

think you made

 

Absolutely.

 

you think in a different way. Right. You're like, we approach this from the wrong direction to a certain extent. Right.

 

Exactly. Exactly. And I, and I think, you know, if you look at the early comparisons between Erlang and Elixir for web development, it took someone a day, you know, to get everything up and running, you know, to be able to serve a webpage versus, uh, you know, going down the Phoenix route, it would take you an hour. And so from a psychological point of view, that was, that was, yeah, that was, uh, that, that, that did it all, uh, you know, and the tools we had were very different to what the tools web developers used to using. Because again, we weren't doing web development. We had no idea what tools web developers needed. And so, yeah, we'd use the tools we knew. So, so I agreed. It's, you know, as you say, web development is not about programming. It's not, you know, which we thought it was. It's, it's all, it's about productivity. It's about, you know, top down development. We used to do bottom up development. Because, uh, and we still do bottom up development because we try to solve the hard problems first for solving the hard problems, there's no point in going ahead with the project because the project's going to fail. There's no point in having a pretty UI if, you know, if, if it doesn't do, if it doesn't solve the problems you're trying to solve. So that's how we did it. We did bottom up and then whenever all the hard parts work, we'd glue them together, we'd integrate them. And, and it worked versus web development. it's top down, you need to see what it is you're developing. You need to see it straight away.

 

To summarize, you could just say, which I think is applicable to a whole bunch of areas, know your audience, right? Know your audience and understand what is actually the problem they're trying to solve.

 

Correct, correct and absolutely, absolutely. And then we didn't know the audience because those weren't the problems we were trying to solve. So, and Jose solved that problem for us, which we're really, really grateful for. And I think that the whole community is grateful for it as well.

 

I think the timing also helped Jose, right? Like I imagine Elixir and Phoenix pre something like Rails would have been a lot different and a lot less

 

Mm.

 

accessible. So like, you know, compared to 2002 when you guys were trying to solve it, it was a lot less clear, you know, what is the, what does the WebDolphin community wants compared to 2013, 2014 when Elixir came out was a lot more obvious that this is the type of template that you can follow that will lead to adoption and then WebDolphin. I cannot think any card away from Jose, but it just was easier to do that post-rails

 

Oh,

 

than post-rails.

 

absolutely. But I think what's also important is, you know, to have ideas and be able to implement them, make sure that they work.

 

Definitely.

 

And I'm convinced, Jose would have been able to do that even if Rails had not been around, even though, you know, it's, I think Rails was brilliant for its time when it came out. Where it failed at was kind of modernizing itself and reinventing itself. And so, you know, it's, you know, if, um, you know, Phoenix and Elixir come out pre-rails, you know, it's, uh, I think what would have been important is that it would have been, you know, able to keep on modernizing itself and, and, uh, and, you know, staying on top of an ever changing landscape, which is pretty much what was, yeah, we're in the tech space, you know, um, you know, everything we do keeps on changing. Yeah, maybe not on a daily basis, but on a monthly and yearly basis, you know things which which which happen You know things which are relevant, you know today will not be relevant in a few weeks, you know a few months time So it's yeah, I keep reminding my students, you know, you're in university Not to learn something but you're here to learn how to learn because we know what we teach will be relevant by the time You graduate And the same applies to any text that we might be using.

 

Except

 

We need to be able

 

for

 

to

 

SQL,

 

change.

 

that thing is never gonna die. Which is fine by me, I like SQL, just saying. But I actually would like to point something out, because I think I've noticed, I noticed like an interesting little parallel now. I mean, Adi, you asked about like you trying also as an entrepreneur, like started trying to start up a business. Now we talked about Jaws and Apache and like how to know your audience. And I'm currently at an employer, which is completely unrelated to Elixir, but we are in the process of like, uh, setting up and like, starting the, um, the implementation of a new product, like a completely new product. And that is currently in the phase of like, where we have a whole bunch of people doing like kind of like market research and air course, right? Like doing user interviews and building up personas and figuring out like what kind of value proposition do we actually want to build for these people? Like what kind of problems we want to solve and what kind of needs we want to address. And it's exactly the same here. Whether or not you actually have something, or you built an app for, I don't know, delivering food to your doorstep, right? Or whether you actually built some new technology to help with web development, there's still always going to be a certain audience you have in mind, a certain value proposition, a certain need you're trying to address. And unless you get that right, Yeah, everything, nothing else matters. If you don't get that right, then you're basically already doomed to fail or at least doomed to reinvent yourself before being successful.

 

I completely agree, completely agree. And to add to what you're saying, I mean, technology comes second. It's important. Technology shows are really, really important, but it's the end product, which is, which is critical. And, and then how you implement it, you know, that's, uh, you know, it's, uh, there's no point in having the fastest, most amazing product if you've got no users on it and, and, and that, that's one of the lessons we've learned as well.

 

Yeah, it can be one of your superpowers, so to speak, right? Like one of the things which make it easier for you to innovate, maybe in the space, you're trying to develop and build your product around. But at the end of the day, I think you just have to look at like a company like GitHub, which everything is still running on rails. It's a gigantic rails app and it's working. I mean, they are successful at what they're doing. Maybe there would have been a different technology to build that. GitHub on and maybe that would have been more successful, but who knows?

 

Well, there was a lot of Erlang in there in the early days. I don't know

 

Oh,

 

if you're

 

okay,

 

aware of

 

I didn't

 

it.

 

know, wow.

 

No, so Erlang was the actual glue which allowed GitHub to scale in its early days. It was Tom

 

Wow.

 

Preston Warner. If you Google it, it should be, yeah, there are quite a few links and references to it. But Tom Preston Warner used Erlang to basically glue together all of the Israel instances. And so, you know, as they became immensely popular, that's why they never had scaling issues. Yeah, there's not, I don't think there's any early. Well, there is early today in the form of rabbit MQ, but, uh, I don't think there's any early remaining in the backbone because of your maintainability problems, and I think a lot of that got rewritten, I believe in Ruby, uh, yeah, later on, but

 

I actually

 

in the early

 

didn't

 

days.

 

know.

 

Yeah.

 

I actually didn't know.

 

Yeah.

 

Wow. Fun little example, I picked yours then.

 

As I said, Erlang is absolutely everywhere, and Alex here as well for that matter, but people don't realise it until things start going wrong.

 

So Ellen, I think there's still this one question you wanted to ask from the beginning. You already came all excitedly in. Oh, I think we lost Ellen, so.

 

run themselves. Nice.

 

Yep.

 

I just said like, Ellen, this is one question I think you wanted to ask from the beginning.

 

Oh, okay. Yeah.

 

Maybe

 

I

 

that

 

don't

 

was the time.

 

know. Yeah. Maybe. Is there any interesting stories where you did an upgrade somewhere and something weird happened?

 

Ha ha!

 

I don't know. I don't want to say too much. I'm trying to let this come out naturally because I'm sure there must be some good story.

 

It's the

 

Many,

 

j- Heheheheh

 

many, many. Software upgrades during runtime are incredibly powerful and helps reduce the cost. When you're shipping a product and you save millions of dollars for every dollar in hardware cost you're able to save, but your product may never go down, software upgrade in runtime is critical. But I think you're thinking of the XC301 switch right here. Is that right?

 

something about dust somewhere, right? I'm trying not to

 

Yes,

 

give away

 

yes,

 

that the end

 

yes.

 

the

 

Yeah.

 

end.

 

So

 

But I

 

it

 

said

 

wasn't

 

too much

 

me, but it wasn't me, but they're friends of mine. It was a product. Yeah, I was very much involved in but there was an XT 301 switch in a country far, far away. In a country far, far away, which was handling all of the international traffic for a very large telco in a very big city. And They'd put in that switch and for years, for literally three years, it kept on running without any incidents, without the need to reboot it. So we're talking late 90s, early 2000s here, early 2000s here. So 20 years ago, we're talking about 20 years ago here, where not rebooting a machine 20 years ago. for three years was pretty much unheard of because there are always issues, memory leaks and so on. But the 63.1 had been running for three years without any problems and switching away, doing what it does best. And after three years, Ericsson went to this customer and said, hey, you need to upgrade because you need to upgrade your system because, um, you know, we're not going to support the version you're on anymore. And so they, and it was tricky trees because they needed to, to, to upgrade it for free versions as a new version, which was at the time being released every year. So what they agreed on is there'd be no outages or no issues. We could allow, um, yeah, we could allow the system to reboot. Uh, you know, instead of doing a live upgrade, which would have meant you're doing free live upgrades and they're tricky and they're dangerous. Um, what we'll do is, you know, we will, you know, we will create some scripts, migrate the data and the state and reboot, reboot the nodes and you know, all the XE free ones had dual pair and active standby node. And so they went in and you prevent all the scripts were in the lab. They tested everything worked. Uh, and so around. come midnight, you know, when you're the traffic and, and in this case, international calls, right? It's lowest. They went in, um, you know, ran all the scripts and rebooted one node and, and this node wouldn't upgrade it. So it wouldn't start. It wouldn't restart. And so panic hit in, you know, they couldn't even get access to the terminal. Uh, the disks just, yeah, nothing was working. and no one knew what was wrong. So they panicked and ran the scripts on the standby node, which had become active and tried to renew it and tried to upgrade it. And even there, nothing worked. The same thing happened. The system completely ground to a halt and crashed and they couldn't reboot the computers anymore. And so... panic. The first line support is called second line support, which get third line support out of bed. No one knew how to restart the switches. It was a country far, far away, so they had no spares. They flew in an engineer immediately who couldn't get the systems up and running. And so eventually a friend of mine, a colleague, ended up FedExing. extra switches wouldn't have worked because it wouldn't have worked because they would have got stuck in customs. And at this point, I think it was the CEO of this big telco was speaking to Ericsson's CEO and that escalated to that level. And this outage lasted a week. A friend of mine ended up smuggling two extra boards in his rain jacket, in his raincoat.

 

Hahaha, wow.

 

into this country far, far away, ensuring there wouldn't be quoting customs, going in, putting them on and getting the system up and running again. And they, you know, and it needs new hardware, everything started running without any issues. And obviously, you know, big post-mortem, they'd been for one week. you know, customers couldn't do international calls in this big city, in this big country, far, far away. So, uh, you know, a huge post-mortem to get down to what the issue was. Now, these were Solaris machines, which were, which, uh, which were running. And Solaris machines, um, what makes Solaris machine, you know, Solaris machines, you know, back in the days had the boot sector of on the external kind of parts of the hard drive. So for three years, what they discovered is that the head of the hard disk, these mechanical disks, which we use at the time was moving backwards and forwards, but never touching the external parts of the disk. So over three years, a very thin layer of dust had settled on the boot sector. because it was never, it was never, yeah, it was never read. They didn't have to read it because they weren't rebooting these machines. And so, you know, three years on after, when they decided to go into reboot the hard drives, the head basically got stuck. And these are hermetically sealed disks. So, you know, you can imagine that the head just got stuck on this very thin layer of dust and wouldn't restart as a result of it. So, You know, once they figured out what the issue was, every, every HD 31, uh, um, switch at midnight started doing, uh, hard drive, mechanical hard drive gymnastics, uh, where the head would go across and start spreading any dust, which was settling on the boot sectors across the whole drive. And, uh, yeah. Uh, and this, yeah, this kept on going, uh, for on. So, yeah, it kind of reminds you. you know, that failure is not always in the software and always be prepared for the unexpected.

 

But like

 

Because

 

seriously,

 

you.

 

how do you prepare for something like this?

 

You make sure you've got staff willing to smuggle in extra hardware

 

I

 

in

 

guess.

 

countries far, far away.

 

We have a smuggler like on retention. You're just one call

 

Yes,

 

away.

 

yes, exactly. Exactly. But yeah, but but yeah, it's all about no single points of failure. You know,

 

Yeah, I guess that's it.

 

I was giving a guest lecture at AT&T in New Jersey. So the old, I think, yeah, at AT&T and I was talking about no single points of failure. And someone in the audience pointed out, hey, you know, You know, the long lines building in Manhattan. So Google, you know, the long lines building, it's the building where AT&T used to have all of its switches, all of its switches, phone switches, mechanical switches at the time, which then became digital. And just talk about no single points of failure. In the cellar of this building, they've got a tank with enough petrol to fuel the generators. for two weeks. So in case there's a blackout on Manhattan, they've got two weeks worth of energy stored in this gas tank, which will allow them to keep on switching calls. And that's how you think when you build telecom systems. And in this particular case, the solution was having a redundant switch or making sure

 

Hmm.

 

that you've got at least two of everything. at least two of everything. But it's a reminder, we tend to go in our comfort zone. And then when things happen, when we least expect them to happen. And I think that's what software is all about. Software development is all about.

 

That long lines building is mysteriously close to the FBI building. Have you heard that?

 

No, but I've heard rumors that the NSA has all of their computers in there right now because

 

Yeah.

 

you needed large buildings back in the days to house huge bulky switches. Right now everything is managed by computers. And it's an example of, it's got no windows. It's built to survive an atomic attack, at least at a distance, obviously. It was the only building post 9 11 in the south part of Manhattan, which was still fully functional after the attacks. So, uh, yeah, it might be closer to the FBI building, but yeah, it wouldn't surprise me if then NSA have taken over parts of it and have their hardware infrastructure in there.

 

kind of reminds me of we have in Hong Kong, we have this HSBC building. And there's always this kind of joke. Have you have you been to Hong Kong before? No, have you seen the skyline?

 

Yes, I have, yeah.

 

Yeah, have you seen the HSBC building looks like a bunch of sticks.

 

Not that I recall, not

 

Okay.

 

off the top of my head, but yeah.

 

There's this building that looks like a bunch of sticks. And I heard from my previous employer, he said, Oh yeah, they build it like that because they can easily disassemble it and move it to another place in case the PLC invades. I'm like, first of all, they're already here. They're next door, by the way. But it does look like you can like, move it apart. It's like popsicle sticks from far away.

 

Yeah,

 

That sounds

 

exactly.

 

like an urban legend.

 

Of

 

Yeah.

 

course it of course it is but it looks

 

Yeah.

 

like a building made of popsicle sticks.

 

Yeah. Yeah. Great.

 

So I always like to ask people this question when they learn something. Francesco, when you started out doing all this, when you started out dating up with this company and with the things you now know and you could basically give your past self a bunch of advice, what would that be?

 

Oh, that's really hard. get an MBA and

 

Hahaha

 

seriously, I think I gave a conference talk, I think it's on YouTube, you know, what they don't teach about running a company when taking your computer science degree. And I gave this talk probably, it was my first keynote, I gave it probably 15 years ago. And you know, the amount of things I've learned since then, you know, I think the problem with You never stop learning. You absolutely never stop learning. And, uh, you know, it's the thing I would probably go back in. If I were able to travel in time and tell myself, you know, back then is, you know, Francesco, you know, in, you know, 2023, you'll still be working with our language, you know, but the programming languages today become an ecosystem of languages, you know, and just do what you're passionate about and, and, and, and, and, and, and, and just kind of follow. Follow your passion because everything else from there will follow. And, uh, and, and I think that that was the conclusion of, you know, of the, of the talk I gave 15 years ago. I think you'll make mistakes, uh, you know, realize what your mistakes are and, and, you know, make sure that you put in place things which you're stopping from happening, um, further down the line and, and learn, you know, keep on learning.

 

Yeah, I know it's a provocative

 

Mm. Mm.

 

question, but I feel it always brings a little bit of

 

Yeah.

 

interesting insight.

 

Yeah. But, but yeah, it's, yeah, we've done a lot of mistakes, but at the same time, we got a lot of things right. So, and I think that's the case of running any business.

 

Okay, folks, Eddie, Alan, any last questions? Is there anything else you would like to add, Francesco, before we move to the fun part of a podcast? The picks. Ha ha ha.

 

Well, no, I'll stick. I'll go straight to the picks actually, because they're very much related Sasha to the question you just asked me. Um,

 

Then we go to pigs

 

yeah,

 

right

 

no,

 

ahead.

 

indeed. And it's, um, so one of the things which happened, you know, becoming part of the trifle group is, uh, the CEO trifle has, you know, kind of what he called leadership workshops with once every three months, four or five different business unit leads. Um, I'm not, I don't need any business units. So I'm more there as kind of an observer and there to learn. Um, we meet in different parts of Europe and you have two days. Where you, we look, we share experiences and we, we, we discuss things. And as part of it, you know, until recently, um, I just gone in and read technical books. There are all the books I was reading, but as part of these, these leadership, um, workshops. And, you know, he and a lot of others who are on this workshop, we didn't suggest a lot of other books which are not necessarily related to tech. And there are three books which I'd like to recommend a lot of people to recommend everyone to read. First of all, I recommend everyone start reading books which are not necessarily focused on technology. You know, we program and we do a lot of coding, but there are a lot of things. outside of coding, which are, are, are, are, are, well, are just as important, especially when it comes to running a business. And, you know, one of the books which hadn't prepared you before coming on this path, but, you know, speaking about it is a remote office not required, uh, by Jason Fried and David Heimler Hansen book written before the pandemic, but which has a lot of really valuable tips about working with remote teams. But also, you know, if you read between the lines, you're managing customers who don't quite understand how remote working works and helping them and educating them. So this is one of them. Um, another book, which I really enjoyed is a book called who moved my cheese by Dr. Spencer Johnson. And it's a book which talks about two, two, two, two mice, uh, in, in a maze. who get used to finding cheese in a certain location. And one day the cheese there is gone. And it's how they interact. And what the book is about is actually about change and how people react to change, but how you should in fact be embracing change and adapting it. So it's a really, really nice story, but which, where again, you need to read a lot between the lines. and teaches you how to go in and change. Yeah, it teaches you to go in and embrace, basically, change. And then another book which I really enjoyed recently is The Art of Thinking Clearly, which by Rolf de Belly. He's got 100 chapters, each just a few pages long. And he goes in and basically... looks at, explains how the human mind works and helps you, you know, make concrete, concise decisions. And I think I had a lot of aha moments when reading this book, in that it explains, you know, things such as nationalism, explains things such as racism, things such as your subconscious bias. a lot of things which kind of affect us on a day to day basis, which which affect us on a day to day basis, which we don't even realize why it is affecting us the way the way it is. And yeah, and and it's and some things you know, you know, as well, or you've learned through time, but that's, that's the book here, I wish I'd read a long time ago. A lot of really, really interesting knowledge there.

 

And thank you for these pics, that's quite an interesting list

 

Yep.

 

of things I now have to add to my ever-growing read list.

 

Yeah.

 

Okay, um, Adi, what are your picks for this week?

 

Yeah, I mean, coincidentally, I have a few books as well today. So one, keeping the whole startup entrepreneurial theme. And I think this book is a lot more relevant in today's world. It's called the $100 startup. It kind of focuses on more of a philosophical approach to, you know, like a side gig ish startup. I mean, it could be a full time too, but it could turn into full time, but like, I think what it focuses on like freedom. freedom as a founder, as an entrepreneur, keeping your purpose and ethics at the center of it. I think it's tricky because today I advise five startups on the side and they range from different, yeah, the CEOs and founders are like an entire spectrum of how they operate, right? It's often easy to lose perspective. Like what is... the original purpose why you started being an entrepreneur. And I think I like the way book ties that back to, the ethos of what you being an entrepreneur is. So I highly recommend that. It also talks about taking it easy as a founder, which these days not a lot of founders do. So a huge fan of the book, highly recommended for anyone who's even think of sidekicks, let alone starting up. company. Another book that I know that I'm not in a startup anymore full time, I have a lot of time. So on top of sleeping more, I also revisiting some of the books that I read when I was a junior engineer. And what Sorry, and one of the books is microservices architecture aligning principles practices and culture again it's tech book overall but it talks about. Cultural impacts in an organization communication impacts and ties and you know conway's law ddd even lean startup methodologies and like. Again, a philosophical book, right? I read this in 2016. I had been working for less than a year. I did not take much out of it. But now that I read it, I took a lot more out of it. So I would recommend that book as well. And an overall conclusion of also revisiting self-reflection, maybe revisit some of these books, and to learn more, get stuff out of it. And you know. four or five years makes a huge difference, four or five years of experience. And if you read a book that's like more experience and philosophy-based, even in engineering, if you read it after five years, you'll get a lot more out of it. And you might even get different conclusions out of it. So also wanna pitch that. My video game pick for the day is Forspoken. Not sure if people have been waiting for it. The demo is out. It's free, you can play that. and I think it will be out on January 24th. But I highly recommend everyone trying out the demo. I have not played much of it, but I have been meaning to play it. This coming out, I am going to play it, but the mechanics are really cool. The way character moves is really cool. It is a little Spider-Man-y, in some ways Spider-Man-y, but better. So, again, a very cool game. Highly recommend it. And job picks, right? So, I have... Now I work at the score and we're hiring a bunch of engineers. So highly recommended company to work if you like Elixir, PedalStack. So go ahead and apply to the score. But two of the startups I advise are looking for a founding engineer. Both just are either about to finish around or finish around. One of the companies, I wrote their entire software, the MVP, Elixir, they even use pedal stack gleam for your full-time job as a founding engineer, reach out to me. I'll put my email on show notes. But that's it for today.

 

Nice, thank you, Oli. As usual, good variety of picks. And Alan, where's my rust book? I want my rust book!

 

Yeah,

 

You need to pick a rust

 

sadly,

 

book!

 

I haven't looked at Russ in a while still. But no, because Francesco is here, I think I picked this one a while back, but I still want to bring it back. Francesco, your book is really useful for me. In fact, I whipped it out. I read it. And then I went to go at a client's office, and we had a production issue. And I used the knowledge immediately to solve the problem. So I was super happy with it. So it's kind of the first time where I actually just read a chapter. It came up in my work to do some tracing. And uh. Yeah, it was super great. So this is a great book called Designing for Scalability with Erlang OTP. Yeah, fantastic pick. I'll just drop the link in here from Amazon.

 

Thanks for that.

 

Yeah, yeah, well, of course, I got to do some brown noses since you're here. But in any case, still, it's a fantastic book. There's a lot of good, useful stuff in here. And still useful if you want to learn how to scale your Elixir apps, I think, because to learn from Erlang.

 

plus one.

 

I just wanted to say, when Adi was talking about his picks, microservices architectures, and I kind of kept back and didn't say anything, but the last four chapters there are the chapters you need to get you thinking beyond a kind of Phoenix sector post press stack, which is great for probably 95% of the problems we might be solving, but not for the remaining 5%. And it becomes very dangerous when you start designing kind of a backend system, uh, as you were a rails app or, or, or a Phoenix app. And I think that's, is what gets you thinking out of the box and thinking differently. It's very generic. So, you know, it's, I think almost timeless, but yeah, it's what you need if you're doing a microservices architecture.

 

Since we kind of went immediately to picks Francesco, there's one part we missed and that is if people want to get in touch with you and have follow-up questions, how can they do that?

 

Twitter is a great way, well, at least when it's still working, which it seems to be. And I think we can post my Twitter handle in here. It's Francesco C.

 

Alright, thank

 

I'd

 

you.

 

love to hear from you. Yeah. And also come with your non-technical book recommendations.

 

Okay, then thank you for being with us on this show, Francesco. It was a pleasure talking to you.

 

Thank you for having me, really enjoyed it. It's

 

Sasha,

 

been too

 

do you

 

long,

 

have any

 

so

 

pics

 

take

 

yet?

 

care.

 

No, I want to smoothly go to the end because I don't have any pics this week. But now you're out on me!

 

That's it.

 

Okay, so yeah, it was a pleasure having you, Francesco, and I hope you have a great day and I hope you all listening to this enjoyed the episode.

 

Thanks a million. Take care. See you soon.

 

Bye bye.