Hey, I'm Kimberly with Elixir mentor Jacob recently added
recruitment services to help companies hire pre vetted Elixir
devs. I help with company outreach, so
if you're hiring, I may be reaching out, or you can connect
with us anytime at elixirmentor.com.
Secure your Elixir apps with paraxial IO.
From code analysis and bot defense to dependency checks,
they've got you covered. Elixir first design with GitHub
integration. Elevate your security at
paraxial dot IO testing. What's up?
I'm Jacob Blitzo, your Elixir mentor and welcome to another
exciting episode of the Elixir Mentor podcast.
This is where we discuss everything related to Elixir,
from interviews with enthusiasts, pioneers in the
community to innovative projects and libraries shaping Elixir's
future. Today I'm joined by Luca, CTO at
Siebel, a Milano fintech for Italian SMEs.
And I'm sure we'll, I'll have lots of questions because I
don't know if I even know what that is.
And Luke is also an Elixir open source contributor with I
believe quite a few libraries of your own out there too, right?
Yeah, something small, nothing major.
Again. OK, nice.
Well, it's good to meet you. It's good to have you on.
So thanks for joining me today. Thanks for having me.
It's a pleasure. I usually like to throw these or
kick this off with kind of like telling us your back story, like
how did you get into software development and what led you to
find an Elixir? Sure.
So, well, OK, that's going a big way back.
I was really young in Milano, I guess attending high school and
I started playing with computers.
That was my, I've always been interested somehow in, in
computers and not really programming at the start since
it was the early 90s and I was, it was the stuff of the Internet
and that was what brought me into everything because it was
the, the new big thing. It wasn't big at all.
So this is pre Google, pre everything we know, we know
today. It was really, I guess, limited
you, you could say in many ways, but also really interesting
because there were early adopters, pioneers, people just
trying to figure out what what to do what, how to use the new,
the new medium. And I was really, really, really
fascinated by, by that, by how you could piece all the things
together and, and communicate with some, someone on the other
side of the world and exchange, exchange information.
That was, I guess, deeply, deeply fascinating for me.
And so I, so I started working for a small ISP way back 20
years ago. And really it was interesting
because you could see all the stack, everything you needed to
go from your computer to, to the Internet, how you could connect
people to the Internet. We, we resolved connectivity.
So it was ADSL at the time, OK. So the SL connections for for
businesses mostly and we operated our own infrastructure.
So routers, BGPDNS, routing and e-mail and Austin, these were
the main things that we were we were selling at the time.
It was an amazing experience because you could see
everything. So in, in a couple of recs, you
know, in a small color color centre in, in Milano, we had all
the, the infrastructure that you need to operate an autonomous
system, which is some what you need to, to, to connect the
Internet starting from scratch, basically, right.
And that was really interesting. So I didn't start in
programming. I started in infrastructure, in
networking, in systems engineering, before
infrastructure is good, before virtual machines, before.
So when you had to operate servers and install servers,
racks, replace batteries or, you know, power units that failed,
you needed to do maintenance, install the operating system,
all all this kind of stuff. I feel like that's a good way to
start. That's like all the hard stuff
and you got it out of the way and you.
Yeah, you. Know, I mean in a way, I guess
I, I saw something that people today take for granted.
So you today you just, you know, buy UPS or use Kubernetes or
something else, mostly services and you are provided with a lot
of infrastructure when you need to start from, from the iron is
completely different in many ways.
Yeah. So yeah, I, I guess I developed
an appreciation for for this kind of stuff and and it's
useful. It's useful to know yeah to to
know how things work. And I learned a lot, especially
about networking and protocols. And that that's something that I
still find interesting and, and, and fascinating.
And, and from there I moved on, mostly because I think I'm.
Very curious person. So I, I like to explore.
I, I wanted to be able to build the things that I, that I was
operating or I was using. And so I moved into, into
software development. So I did at first native mobile
for on iOS. It was 2010 I guess, when the
iPhone 4 came out. OK.
And that there was a big market for, for making mobile
applications. And so I started from there
working in a consultancy where I had the opportunity to work on
big applications. So banking apps, the, the
biggest one we did was an app for training Italia, which is
the, the train company in Italy to, to buy tickets.
So it was also apps that were used by by a fair number of of
people. And yeah, my I guess that my my
background in C and because iOS at first was developed in
objective CI. Remember that.
Yeah, strange mix between small talk and and.
CI struggled, so you and I kind of have a similar path.
I first started as an iOS developer as well, but it was
like right on the brink of when Swift was getting introduced.
So that was. But Objective C was so hard for
me, I don't know why. I just, I struggled with it and
then when Swift came out it like everything clicked and that's
when I started becoming a real software developer.
Yeah, yeah, I can see that because yeah, it was a bit
strange. I mean Objective C is as some it
just increases I guess. And also the the first versions
you didn't have memory management, so you needed to do
manual reference counting this kind of stuff.
It was, yeah, not always the the easiest thing if you are used to
to memory management and to garbage collection, this kind of
stuff. That's why I love elixir.
Makes our life so easy, doesn't it?
And yeah, sure. So yeah, I did a few years of
that. I enjoyed it and for for the
same reason so that I wanted to do to have different experiences
and and do different stuff. I got into front end development
and then in back end development and I worked for a few more
startups. I also worked for one of the
biggest, the three big tech companies in Italy doing mobile
phone services and I worked there and that's really when I
came in contact with, with Elixir.
So I, I started being, being interested in it first as my
personal interest and then I, I also somehow brought it in my
work and used it to, to some extent to, to build what we were
building. But really the like the, the
start of it was my interest and the fascination.
I, I never used the functional programming language before
Elixir. And somehow for me it clicked.
It clicked immediately. So I, I, I had the impression, I
said I, I, I don't know why. Why didn't I know about this
before? I know that's what I said.
I struggled with object oriented programming and like JavaScript
for like 8 years before I discovered Elixir.
Yeah, yeah, I, I get, I get the sentiment.
Me, me, me too. Is I don't know, it almost felt
like something that needed to exist.
And, and I, I, I found it. I saw it before my eyes.
And I said, OK, pattern matching words.
I mean, all this makes sense. No mutable state, no
complicated. Well, like the way I always say,
and I probably annoy everyone that's listening 'cause I say
this every episode. But like, I feel like your
engineering mind works like an immutable language, like you
transform things and you can like watch it go through, you
know, each function that gets passed to and you, you get
exactly what you expect from it, you know, And then with object
oriented, you can have basically you can alter state from
multiple places and it just adds just a lot of confusion and
potential bugs, you know? Yeah, exactly.
I think it removes a whole lot of complexity that somehow it
condenses everything in a simple model that it's really easy to
reason about and to debug and to follow.
Yeah, and I feel like someone that's an engineer, you break
things down into steps. So it's like already fitting
into the natural way that you solve a problem.
Like, OK, now we have to do this to it, then this, then this.
And you know, you just step through things.
Yeah, yeah, that, that's, that's what I think too.
Yeah. It's really straightforward once
you get the, the model, the way you, you split things into
functions and you have the ability.
And so a lot, a lot of of things, a lot of problems that
you normally have in, in other models in in object oriented
programming just disappear. And you, at least for me, it's.
It allows me to focus on on the problem.
I. Agree.
I think that that's what gives. And your tools just work, and
they're there for you. Yeah, yeah, exactly, exactly.
I I I don't have the feeling that I'm somehow fighting the
the tool I'm using right too much.
And JavaScript, you're fighting the tool.
Yeah, and I, I don't know, I don't have a lot of experience
with JavaScript. I never liked it a lot.
It was really confusing for me. It it it does everything and and
nothing. It does everything but nothing.
Well, that's what. So did you kind of you went from
kind of an iOS developer straight into a back end with
Elixir then and then that kind of became your main language or
was there? I used a number of things.
Over the years, so I at the beginning, when I was a System
Administrator, I was working with C with per with some PHP
and but I didn't really enjoy it much.
Then I moved into Objective C, which was was kind of familiar
and it was interesting before because it was a really, at the
time, IUS was really a rich platform.
So you, you had a lot of stuff around you.
It was really interesting to, to be able to work with, with
hardware, with maps, with a lot of new technology that was
coming out at the time. And I enjoyed the the language
too. I did a bit of Python for the
back end stuff, also for said projects and then yeah, then I
moved to to Elixir. OK, nice.
Yeah, I was, I went through kind of a gauntlet of languages, but
I've, I, I enjoy Python, but I've never used it more than
just like writing a few small scripts.
So I don't actually know what it feels like to be in a a large
code base, but I've always found Python fun.
Yeah, to. To some extent, I guess I don't
know. It's never really also never
really clicked for me. It was a strange mix of
different things. So you you had OP and you have
some some extent of functional programming, but.
Also a lot of ways. To to shoot yourself in the in
the foot and. I I've done some like small
embedded projects with it. I need to make time to play
around with nerves and get back into doing some IoT things, but
that's been on my list for months now and I still haven't
done anything. But one of those days I want to
play with nerves. So that'll be cool.
So let's talk about C Bill a little bit.
What is it and what what like, what are you changing in like
the fintech world? If you could give me like a
quick elevator pitch of what what problem you're solving.
OK. So civil is a cash flow
management system for for small and medium businesses.
So the what we started from four years ago is really simple if
you think how Italy works. And so I'm going to give you a
little bit of background, otherwise you won't be able to
follow. So in Italy, small and medium
businesses are the vast majority of businesses that you have.
So more than 95% of businesses are this kind of business and
some are really small. So like people having a really
small company, maybe they're working, I don't know, they are
plumbers or electricians or these these kind of people up to
companies that make 12345 million EUR a year.
These are small and medium businesses, and historically
they are underserved. Wait one second, I think we
might have lost too. So, so let me let me try and
start from from scratch. So as I was saying, we've built
the service for small and medium businesses, 12 small and medium
businesses control their their cash flow.
So to be able to to manage the finances and, and the business.
And what what we started from was building something that
would connect their bank accounts.
So we like our users do an authentication flow in with
their bank inside our app. At the end of this flow, we are
able to import their bank accounts, the more much and
those all the transactions these are bank accounts and this is
due to something we have in Europe which is open banking,
which is the ability to. So this is a law from from the
European Union from a few years ago and it mandated that all
banks provide us as via APIAPIS to to the information on all the
bank accounts, citizens and companies in the in the European
Union. So we can do this.
And for this we import and keep updated all the information from
the business bank accounts. So we know how much money you
have and we know the transaction you have and we keep them
updated regularly. And we do the same thing with
invoicing because in Italy we have something that is quite
surprising and advanced. But we have initially operated
electronic invoicing system which allows you to access
electronic invoices and do the same thing.
So we are able to import all the invoices that you have both that
you issue and that you received from from other businesses and
and show you this information in the application.
And so based on this, we built a way to categorize all this
information. And then we built analytics
mostly. So tools telling you where you
spend money, where you gain money, how much money you have,
and also some kind of simulation of how much money you will have
based on invoices that you receive, based on invoices that
you issue and those on simulations that you can run.
So if you know that you will receive some amount of money,
you can, you can inserted in, in the, in the application.
And then we will somehow simulate the cash flow for the,
for the future, for your future. And that's it.
That's what we we started from. And then from there, we started
to build a lot of other stuff because the goal, the end goal
for for CIBIL is to build one tool that allows you to manage
your company both from the financial perspective and from
the administrative perspective. So one single tool to do all
this. So over the course of four
years, we added a lot of features like for example,
invoicing. So you are able to manage all
the invoicing needs or other documents, for example, for
shipping or other stuff that companies normally need to do to
documents they need to produce. You can pay your bills from from
the application. So you can pay also using open
banking and other means. You can manage your payments
schedule. So you can know who needs to pay
you, who you need to pay when and organize all this.
Mostly this yeah. And and a lot of different
little features that allow you to to to manage your business
completely. This is it.
OK, awesome. Very cool.
I'm curious, did you, did you start when you started building
C Bill, did you start with Elixir as your back end or did
you did you change over to that? So, yeah, Greenfield does not
exist in a way because, yeah. So I, I joined the company, we
were five people, but there was an existing MVP which was built
to do fundraising and to validate the idea with, with
some, some early adopters. And this early MVP was was
written in. Part in TypeScript, part in
Python, and it was built externally.
So I joined the company when some some initial funding
arrived and we were able to start internalizing development
and build the real thing. And so, yeah, from that point
on, what we did was mostly rebuild the MVP, which was
really small in in Elixir and then grow it from there.
Yeah. Nice.
Now did you already know Elixir was the choice?
Was that what you wanted to go with?
Because one, I mean, I think it's a perfect fit and I think
finance and fintech are perfect, perfect like use cases for it.
But I'm kind of curious what your thought process.
Was, well, it's not like linear, you know, So actually what I
did, what I, what I started from was something that wasn't
working in the MVP and that I thought Elixir was a great fit
for. So as I said, we synchronize a
lot of data. So imagine that if you have a
business in Italy, you normally have between two and three bank
accounts and you, and then you also have all the invoicing that
you do through the through the national invoicing system.
And we connect the stuff for you.
And then we keep it synchronised.
So we keep it updated a number of times per day.
So maybe 6-7 times a day we synchronise all the banking data
for all our customers. Once a day we synchronise all
the invoicing data for our customers and the regional MVP.
This was the critical part because it wasn't really
working. Also at a small scale, it had a
lot of problems. It was very difficult to to
operate, so the first thing that we built was this
synchronization engine. I'm curious, are you using Oban
for that or did you roll out your own solution?
No, not Oban. OK.
We're using Broadway. OK.
Yeah. So you got a Broadway pipeline
coming in? Yeah, we kind of multiple
Broadway pipelines. And so, yeah, we that's the the,
the basis of it. And then on top of that, of
course, we have a lot, we have a lot of logic that that needs to
run to, to synchronize all this data, all this stuff.
And that was the first thing that we will build in Excel.
What are you shooting to the Broadway pipeline for?
Like are you using like Lambda functions or how are you
handling that? No.
So initially it was we were using SQS as a source and then
we were just attaching Broadway to, to SQS to execute
synchronisation jobs. And then we moved progressively
towards Rabbiton queue because it offers more flexibilities in,
in, in a lot of ways. So SQS is, is is nice, it's
really easy, but it's also really limited.
So you mostly have a worker queue that that's what you get
with SQS. With Rabbiton queue, you get
complex routing, you get a lot of stuff.
And also we were able to build other things using it.
So it was like a logical choice. Yeah.
So that that's mostly Rabbiton queue connected to, to to
Broadway for for pipelines. OK, cool.
And then how are you scheduling like what?
What determines when you're syncing accounts?
Or is it all time based? Or does it depend on the user or
the business? A mix of things.
It's mostly time based. So once we have connected your
So in order to connect your bank account you need to perform
authentication with the bank. So the user needs to to put
input his credentials go through the authentication with the with
his bank. Once you have done this, we are
able to synchronise your data. So the the first synchronisation
is done when the user completes the authentication.
So in real time let's say. And then from from there on we
have schedule syncs for bank accounts.
So six times a day time based we do synchronisation for which are
smaller though because we don't need to import the old data, we
just need to update the the most recent stuff.
Do you have to ever worry like as your user base grows will
will you have a weird bottleneck doing time based or would you
just kind of break things up and have just different time bases
across your user base to handle handle the traffic or whatnot?
Yeah, it's changing. It's been changing also we've
had some challenges. We we started with something
really simple. So just let's have a queue on or
a bit on queue and let's connect broadly to it.
And this worked fine from I guess 60 to a few 1000 users for
our for our use case actually it's work.
It's work actually surprisingly well.
I guess we never had scaling issue with this kind of set up.
At some point we started noticing that there were some
cases where this was limiting and also it had problems.
For example, we allow users to connect other stuff other than
banks. For example, we have customers
that are e-commerce sites that, for example, use Skype to to
cash to cash in transactions. And some of those they have
really large volumes of transactions.
So maybe they sell stuff which is cheap, but they sell enormous
volumes of it. And the problem with this is
that our synchronization pipeline was built in a way that
you had to complete the whole sync process and you so you
started from consuming the message from Rabbington.
Q And and and you had to complete those in process.
But at at some point we have, I don't know, a customer with a
million of transactions that we need to synchronize.
And at some point you are unable to complete that in a visible in
reasonable time, right? So so the the consumer times out
the the message gets back into the queue and then you process
it again and and it blocks everything.
And then you got a nasty loop right there.
Yeah, exactly. And that's problematic.
So what we we started to do was starting to split this
synchronization process and split it by provider and let me
say. So the banking part and maybe
Stripe, maybe PayPal, maybe other providers that we we sync
with and started chunking the works for the synchronization
service gas and fetches some data and then it passes a chunk
back. So nice.
And then it's resumable too, right?
You kind of can track the progress.
With chunking. Or not really.
No, not really. You you mostly solve the problem
that you don't need to fetch everything and then save
everything, but and do it progressively right?
And so you are able to eventually complete the sync
even if you have a very large volume of data.
Yeah, I always feel like it's cool to like hear everyone's
like growing pains, right, 'cause everyone life is great
when you have like a really small like MVP product and only
a few users on it, right, 'cause you don't run into problems or
synchronization issues. And the more users you get with
synchronizing on a time base, right, you might not even be
able to finish the whole task before it starts synchronizing
again, too, right? That could be another potential
issue. Yeah, absolutely.
And so we, we started like we, we obviously, as you might
imagine. So picture Sybil 4 years ago is
just Luca doing all the, the software engineering and OK, so
let me solve this in the simplest possible way.
And also we have 100 users. So who cares really?
Because maybe if, if we have 1 user that is problematic, we, we
can just like tell him that this is not possible right now and,
and we'll skip it and we'll move on with our lives.
Today the engineering team the like the technical that I manage
is 40 people. 40. Slowly.
Yeah. Wow, that's so.
Slowly, I'd say medium, yeah, size team.
So not huge, not small, not huge.
But you're getting there. You're getting huge.
Well, that's, I think that's mostly because you know, Civilis
is a venture backed company. So even though we are an Italian
company, we are backed by venture capital funds which are
international. And so our growth is that kind
of growth. So it's basically doubling every
year, right? Yeah, at least doubling every
year. Yeah, that's crazy.
It is kind of what's expected. Yeah, it's also really fast.
That is, that is, I'm curious, are like you being the CTO, are
you still in the trenches? Are you still writing code or
are you more managing and doing high level architecture and
planning? Way less than than before
obviously. But I I enjoy coding.
I enjoy solving problems. Maybe if I'm not the one coding
directly the the solution. Still, I I enjoy problem
solving. I think that that's what every
like technical person likes to do.
And so if even if I'm not writing all all of the code
anymore, because I'm not I I love to design the system.
I love to solve these kind of issues and, and the fact that
you go, the more interesting it gets right with others that you,
you encounter. So I think there's, there's some
kind of a degree of, of the quality of the solution you're
building. And it's inevitable that when
you start, you, you start from something really simple, from an
MVP, you solve part of the problem more like when time
passes and you go on and you, you observe the system and what
happens and how customers use it.
I think what changes is your understanding of, of the problem
and also your understanding of the solution that you get and
even of, of its limitations. And then you slowly start to to
grow it right, to make changes to, to adjust to to the new, the
new reality. Yeah, that makes sense.
All right, we're going to put this on hold for one second and
we'll be right back. Coding Elixir with AI or
building AI into your Elixir apps.
The Elixir AI Collective Discord is your community for both.
Link in the description below. Hey, I'm Kimberly with Elixir
mentor Jacob recently added recruitment services to help
companies hire pre vetted Elixir devs.
I help with company outreach, so if you're hiring, I may be
reaching out, or you can connect with us anytime at
elixirmentor.com. Yeah, the ocean and we're back.
Yeah, they like, you know, the amazing we take for granted just
being able to chat across the world, right?
And you don't really think about the complexity there.
Yeah, that was what was I saying earlier, that I, I, I was always
fascinated by, by this, by telecommunicate, by protocols,
by you. Know, I mean, it's insane like
the hardware and just how everything works, like the
network of complication and just everything between you and I
right now and video streaming. But we're still capable of doing
this Pretty cool. So the the hot topic because we
can't avoid it. It's like all we do is talk
about AI now in software development.
I'm curious, what is your take like being in fintech, worrying
about security, like you have a a lot more like regulations and
things that you have to be compliant with.
How How has AI kind of changed the way your team is developing?
It does inevitably, I'd say it's a great tool.
So it's, it's an amazing tool. We, we are figuring it out.
I, I guess collectively everyone, not not me or or
Sebil, but I guess everyone right now is trying to figure
out how to use these effectively.
And so I don't have an answer because I think that the issues
behind these are so big in terms of so I don't know, let's let's
just me throw something on the table, IP issues because you are
including code in your product that is coming from something
that is trained on a lot of code and code you don't know about.
So you don't know what's in there.
Then you have, as you were saying, security issues because
who that's what these tools write and how do you manage
this, especially because at least I don't know, this is my,
my feeling. But what happens when you when
you start using AI tools for development is that AI produces
a lot of code, probably more code that that you would have
written yourself. And that's great because you
didn't have to write it. It's also a problem because it's
good. And so you didn't.
Write it, yeah. Hopefully you read it, but.
That's Oh my gosh, that actually remind like side tangent and I
won't, I can't throw anyone under the bus, but I have a
buddy who works for a fintech company and he was just told
he's more he's like a lead engineer.
So he has like the CTO and couple people above him, but he
was just told that they're no longer doing PR reviews as
developers. They're going to let Claude code
do it. And that is that was the most
terrifying thing I've ever heard.
I was like, look like my, like my day job, my engineering team
that I work with, we love. Like we talk about how we use AI
in our workflows. We've built some tools to make
it more useful. But like, we're buckling down
and like, review is even 10 times more important than it's
ever been. And to hear a company,
especially in the financial world, saying that they're going
to just let Claude review their code and that's it, I think
that's terrifying. Yeah.
It is in many ways.
I don't think we are going to solve this today, Jacob, But
yeah, it's a big issue, I guess in terms of security, in terms
of privacy also, because a lot of companies right now are
integrating. So they they do AI in, in in a
way which is they are integrating APIs from from
measure measure AI players. So maybe they're integrating
with open API, open AI or, or on Tropics AP is and they're
shooting user data at these APIs, right.
And this is also huge, huge issue, more so in Europe,
because in Europe we have GDPR and we have AI Act.
So we have regulations that have deep, deep consequences also
financially if you breach those. I'm against regulations, but I
support those kind of regulations like, you know, user
privacy and all that is so important.
Yeah, Yeah. No, absolutely.
I mean, some, some some degree of, of, of protection of, of
user data is, is absolutely necessary.
I guess it's also challenging though, because as a business
you are expected to comply with all this stuff no matter the
size of the business. So if you have a small company,
you still have a lot of stuff to cover.
So it might, it can be challenging to to operate the
SAS business with under this kind of of constraints.
But yeah, of course, they are also necessary because
otherwise, especially Fintech, as he was saying, especially
when you have financial data of companies, a lot of really
critical data about your users, you need to be able to somehow
protect them. And yeah, I, I guess AI,
especially AI coding poses a challenge for this.
It's. Yeah.
It's complicated. Yeah, it is.
It's very complicated. But I think like one thing we
always have to remember, especially like being engineers
and building things, right, you have to, it's like your
responsibility to protect the data that you have on your
servers and databases, you know, like even if regulations and you
weren't, you know, threatened with fines for leaking privacy
info, you shouldn't want to, right?
Your customer should be able to trust you and you got to keep
that data close. Like I have a huge problem with
companies that will sell, you know, user data and things like
that. And I know like most social
media platforms, that's how they survive and live, but it's just
always has irked me. And I think it's like kind of a
gross way to make money in tech is to sell data.
Like why don't you just provide a service you know?
Yeah, yeah, of course. I mean, so we, we are into
social networking. We are not head support in any
way. Of course we we care about the,
the, the, the data users and trust was because it's our
business to do that. And so to be, to be secure, but
you also have to confront the reality of, of, of the world, I
guess where talking about security, talking about privacy,
all these aspects are often times overlooked when you are
building something because it's not the, the main thing that you
need to do in, in that moment, right?
And then somehow this stuff gets overlooked.
Or let let let me put it this way, if you're an engineer
working at a company, I don't think there's a lot of
incentives around you right now to to be mindful about this
stuff. I think there are more
incentives around you to be burning tokens on AI.
To move quick, right, move quick, get that feature done.
Yeah, absolutely, absolutely. And so I think that especially
in mission critical environments, especially when
you have constraints around you, speed is something different,
right? So you you cannot define speed
in terms of the output of or the amount of code that you're
producing everyday. That that's more of a liability
in in many ways, right? Yeah, I've been seeing these
like generated charts to where employers are like trying to
track how productive developers are by like lines of code
committed. And that I was like, I mean, I
get it, that is a data point, but I don't think that means
that they're working harder than a engineer that committed less
lines of code you. Know no, of course, because.
There's a lot of thinking that goes behind building.
Absolutely. I mean, you, you can judge a
book by the number of pages, right?
So and it's a masterpiece and it is a really small book, so.
Yeah, exactly, exactly. So I always find like you always
have a like the manager level people always trying to analyze
and put production numbers on. Like I feel like engineering is
like very. What's the word I'm looking for?
Like it's creative work, right? So.
You're not always going to just be a producer.
You also have to like, you know, come up with solutions.
You're going to be reading a lot of code and you, you have to
like, think a lot. And you're also not always going
to be, you know, an athlete with the best solution instantly,
right? Sometimes you have to go for a
walk and you're like, oh, dude, that's how I fix that problem.
And so, like, you kind of have your ups and downs with
productivity, I think, as an engineer, yeah.
Absolutely, yeah, I, I think we. Never got around to to find a
way to measure engineering work or let let you, you put it
correctly. I think creative work because
it's not just engineering, it's engineering.
But maybe the same thing applies to design and and other things.
I think we we, we never. Managed to.
Find a way to. Or I don't.
I don't even know if there's. A way to, to, to do this so we,
we still look at at engineering or design or or other creative
disciplines as like the worker in the factory, right?
And, and you, you can't measure it that way.
It's not possible to merit right.
It's not just all production, but still.
Somehow. Yeah, but it isn't right because
you, so it's, it's, I think what what I was saying earlier is
that you are figuring it out as you go.
So as you go, you understand the problem better and you figure
out the solution better and you build the thing and you
continuously rebuild the thing. And this is fundamentally
different from building the same thing continuously all over
again, right. Yes, Well, like I always.
Look at like software development, especially when I
was running like a consultancy, everyone like a lot of times
clients that aren't familiar with how software works, they
think like it's one set cost. I'm going to get this product
exactly the way I want it and then it's forever done and wash
my hands of it and it'll just produce money.
But like software is a living entity, you keep doing
iterations, you keep fixing things because like you said,
like you, you solve the problem that you have the current
information for. But that problem shifts over
time as well. Yeah.
It's at least. To me, software engineering is
really a learning process. It's not a production process.
Right. So the like, like software is
really, so working software is really decide the fact of the
learning that you did. And without that learning part,
you cannot really have the working software part.
And I think this is really the, the legacy, I, I think the most
important legacy of Agile of, of the 2000 software engineering
movement that led to agile and, and to, to changing the way we,
we think about software engineering.
Because the, the fundamental thing that you need to, to do is
learn something about the problem you're solving And, and
that every, everything follows from that, right?
I think that's I, I got somehow a bit too philosophical, I
guess, but that we, we started from from AI, right?
Yeah. Well, I.
Think like these are good conversations, though, because
when you hear about these like, nightmare situations that other
people are doing, you're like, who's making those decisions?
You know, like who who decided it's a good idea that they're
going to fully trust Claude code to do code review for their
entire team? Like I personally don't know any
engineers that would say that's a good idea.
Like, I don't know, it's just wild to me.
Sorry I I lost you for. A minute.
Oh, I don't, I think. Oh, you.
Lost. Did you?
You missed what I said or are you good?
Yeah. Yeah, I lost your food.
OK. I think you were.
Good on my end. But yeah, I was just saying like
to go like back to where I was like my buddy was told that
they're no longer doing PR reviews.
It's just unheard of. Like I don't think I have any
engineers in my day-to-day life that would say that's a good
idea. Like even people that are.
Gung ho and. Love AI and like letting it
write your code but everyone is still reviewing their code as
far as I know. No, that, that's.
I mean even. It depends on the context.
For example, counterexample I, I I want to give you is is I I, As
I said, I I've always been interested in networking
protocols, right? And so one thing I did I started
doing when when levelling lexer actually 10 years ago was
building my own Http://implementation most for
learning purposes. So HTTP just came out.
So I wanted to understand the protocol.
And so I started reading galaxies and I, I started
playing with maybe, maybe I could implement these in Elixir
from scratch. So just using what, what the
beam and dot P give you. And let's try to do it right.
And I did and it was really interesting and I came up with
something which worked and, and I was really happy about the
process and I learned a lot about it.
And then HTTP 3 came about and it was really complex and, and
like much more complex than than HTTP One or HTTP 2.
And I never actually managed to. So I always wanted to add that
to my my implementation, but I never managed.
One month ago I I said, OK, let's let's try because I saw
the Matt Trudel so the the author of Bandit, which is one
of the major Http://implementations for for
Elixir. He had the PR open and divide
byte coded HTTP 3 support into into Bandit.
And I said, OK, so maybe let me try, right?
Let me use Claude and and try to webcode the thing and I did it
took me 4 hours, 11 evening, 4 hours and 100 bucks of of tokens
for that's just awesome. I will say that's.
Awesome. Like, but you're also not
blindly generating that. You're still reading it and
probably putting an understanding behind it, you
know? Yeah, no, absolutely.
Because it had, of course. It had the framework, so it had
my library with the obstructions, so it knew in
general. Our our implementation.
Would look like I I inted it in implementing something like
other compression, I don't know Q pack or the Http://protocol
part, but the the IT also made stuff up so you made mistake and
I needed to somehow put that race around it and maybe correct
some mistake. But the impressive thing is that
after 4 hours of byte coding and I've not read a single line of
the coded throat, after four hours of byte coding, it was
able to make an HTTP request. And that, to me is fascinating
because that is. That's very cool.
So. For and I guess my point.
Is I'm sure that when you try to put to take these tools and put
them in a mission critical context, in a business context
where you have to need to have certain guarantees, that's
problematic in many ways because of everything we said before.
At the same time, what I found is that when you want to learn
something, when you want to do exploratory work, when you want
to maybe build the prototype and find out how we can look like,
these are amazing tools like it really is.
We have. Medved talker, he said.
I thought about this a few months ago, bringing elixir into
fintech, and I said elixir is the perfect fit just because you
have just the nature of the beam, right?
It just, it works. The fault tolerance, the
supervision. Trees like, you know.
Anything that fails starts back up depending on your strategy,
whatever it may be right? It's just self healing.
It's perfect for for financial stuff, yeah.
Absolutely financial stuff for I think all things web in a way,
all system that you need that need to be resilient, that need
to be soft real time, that need to to have certain capabilities.
I think it's a great fit for a number of things.
Me too. I always think, I think it's the
perfect. Solution for everything, but I
might be biased, I don't know. I just haven't found one where I
wouldn't be like use elixir. I don't know.
I'm not sure. I think that that there are of
course reasonable cases where you want to do something else,
even though there are efforts. There's an Italian guy who built
an implementation of the Beam for microcontrollers, right?
So really constrained hardware platforms where you don't, yeah,
like limited resources and things.
And yeah, yeah, exactly so. And you built this this.
Implementation which is actually quite popular is called Atom VM
and it's a re implementation of the Beam for for
microcontrollers and and limited hardware.
And so to some extent you, you can leverage that, but I'm sure
that there are plenty of use cases where there are better
tools for, for, for building what you need to build.
I just find that if you build web stuff, if you build the kind
of things that we, we build to deal.
But I I think vast majority of the software produced in the
software industry is is a good fit for for something like this,
at least compared to other solutions which I agree.
I mean, what's? Kind of nice too, like.
When you start up as a start up with only a few users, just
picking an elixir and writing on the beam makes scaling a breeze
when you get there, because one, it's super efficient.
You probably need like one node for a very long time.
And then when you need to scale and distribute, it's very easy
to do. Yeah, I'd say.
With the with the beam, we would that be league zero and with
whatever language you choose to use for for it, going from zero
to 10 thousands of 20,000 users is basically free.
So you don't even notice that that you are.
And that's not true necessarily true for for other stuff.
I I don't want to. So I'm not trying to bash any
any technology. I'm just saying that a lot of
the languages which are Luca, you can bash technology, it's
OK. No, no, man, I don't want to.
I don't. I don't want to.
I I just. Think that, but I don't think
there's there's like the reason is historically historical
mostly so and it connects to what you're saying.
So one of the great things, so everyone mentions the beam for
parallelism and concurrency and this kind of stuff.
I don't think it's a great. It is the greatest feature of
the beam. In my experience, the greatest
feature of the beam is full tolerance and resilience.
So the system is really stable. It is really hard to crash it
completely, to take it down. It's it's something that I think
is really is really, really important.
Sometimes it's hard to know if it keeps.
Rebooting, you know, like, yeah, because you don't know.
It's too resilient that that happened to me.
Yeah, that. That happened to but but that's
great that that's not true necessarily of a lot of other
stuff. And the, the parallelism and the
concurrency really came later because in the early 90s when,
when the beam was was born, real concurrency wasn't there.
The reason in Abdul wasn't there.
So the problems were really, really, really different.
And it was born mostly for for fault tolerance right languages.
Which were. Born like roughly in the same
period. So and we are talking mainstream
languages because we're talking Python, we're talking Ruby,
we're talking all all this kind of stuff really struggles with
with concurrency. So if you, if you need to scale
those kind of languages because of the same reasons they, they
want, they, they have problem like you, you, you're sort of
multi threading or multiprocessing, but of course
that's resource intensive. So you, you have a lot of issues
with, with scaling that, that kind of technology.
The the amazing thing is that the BEAM kind of solved the the
parallelism and concurrency stuff without wanting to solve
it, and you don't have those. Kind of problems when working.
With with the beam and and that's that's amazing that
that's it is it's you don't even really have.
To think about it either like it's just it works.
You can just spin up a process for whatever you want to do.
And even if you're not constantly using Gen. servers or
anything, just using live views or Phoenix, like you're using
Gen. servers with ease and you don't even realize that it just
works out-of-the-box. Yeah.
Yeah, the the. Yeah, I guess the, the
concurrency story is not so easy when you start to get into it,
because it then you, you start to understand that you have to
model things in a certain way, that processes need to be
managed, that you need to structure your supervision 3,
that you can't just a vision server because eventually it
will become the bottleneck if you have too many requests or
everything else for it. At the same time, it is true
what you say is true. So you use Phoenix and you, you
already have this built for you. So, so you, you don't realize
what happens backstage, but in fact you are using the processes
a lot and, and it just works, right.
And when you want, you can dig into that stuff and start to
understand the, the primitives of the system that that's
really, that's amazing. I think like when I first
started writing. Elixir I wrote wrote.
I hear some feedback, but is that me?
I might be looping through your microphone.
I think a little. Bit yeah, that's strange because
I didn't change. Anything.
Well, let's see. I'll.
Just talk. Yeah, a little bit.
I don't know if you guys are, if anyone.
Listening. Is my feedback bad?
If it is, we'll figure it out. If it's not, I can hear you just
fine. I don't.
Hear anything? OK, I'm just watching.
After I talk, it comes back through on on your mic levels a
little bit. Let me see.
Maybe I can, I'll just turn on. A noise gate.
Let's see, maybe. OK, well.
It seems. OK, now.
Nope. Nope.
There I am. Or or I.
Can just mute myself while. While you're talking, all right.
All right, yeah, I guess that works.
We'll do that. Now I forgot what I was going to
say but. Well, we're talking about
supervision trees. Oh yeah.
When I first started writing Elixir, I didn't know what I was
getting myself into. So I was like writing Elixir is
like just a Restful API product, like just doing my thing,
writing it like I was writing a node JSAPI and I learned a lot.
But like I like at first I fell in love with the syntax of
Elixir and then I started understanding like the
supervision tree, Genservers, like OTP, all that cool stuff.
And but I feel like I wrote Elixir and wrote like endpoints
and things for like 6 to 8 months before I even started
like harnessing the actual power behind Elixir.
And then once you fully grasp that, like the power, you're
just like, why haven't I? Been using this my.
Entire tech career. And that's kind of why, yeah.
Yeah, go ahead. I had that feeling too.
Also, that's what I struggled with, especially in the
beginning. So I guess 10 years ago I
started a little bit more than 10 years ago, I started playing
with Elixir. And what I struggled with while
learning was trying to put all things together so that the
language is pretty straightforward.
But learning how to piece the OTP and all the all the
processing stuff together with the the business logic was
really the most challenging part for me.
And I I also think that's because 10 years ago there was
way less knowledge available on the Internet.
There were way less books. In many ways, I think that they
were somehow were well kept secret of the airline community.
You know, a lot of stuff that the the airline community took
for granted, but that wasn't really so easy to piece
together. And so, yeah, that that that was
I guess the most challenging thing for for me too.
That that's also, I think one of the big merits of the OR Elixir,
which is in the end, just a thin layer on top of of of the BMN
dot P. But the, the big merit of Elixir
to me is making all this stuff accessible, like easier to
assess rather than like the, I think the tooling, I think mix,
I think documentation, I think unit testing, I think all the
things that you need, the experience that you have when
you install Elixir is everything is there and it, it works,
right. And you don't have to start
picking tools, external tools for doing everything that you
need to do. And also you have a lot of
documentation and a lot of books and tutorials from the community
that today help you grasp these and understand how, how you
build the real application, not just experiment with the
language. And 10 years ago, it wasn't
necessarily the case. Yeah.
And I. Think like Elixir.
Brings kind of like a modern syntax, right to I think it kind
of revived Erlang because I don't think like Erlang should
be way more popular than it is. But I think it's like it's a
difficult syntax. It's not easy to write.
It doesn't seem natural to me. And I think just Elixir kind of,
you know, being that modern syntax, fun to write, easy to
read, it kind of it brought the attention that Erlang deserves a
little bit. Yeah, yeah, sure.
Yeah. Erlang, I, I don't have much
experience with Erlang because I started straight with, with the
leagues there. So yeah, I, I can navigate my
way through Erlang code, but I'm, I'm not really expert in,
in, in Ireland. Same.
I'm the same. Yeah, it's, it's a bit baroque.
I'd say it's, it's quite strange, I think.
Yeah, syntax made it more accessible to maybe to also to
younger people to, to, to people not used to, to that kind of
syntax, but also tooling, I guess because for example,
having a package manager. So a lot of stuff, at least when
when I I looked at it earlier, like I think.
Raybar. Came not so long ago, and before
that you had. The standard way was MC5's,
which is totally fine if you come from that background, but
maybe having a scaffolding tool, having a package manager, being
able to so having some kind of more easy developer experience.
Also, for example, another thing which happened and I remember
that is integrating releases right in, in mix that that
that's amazing. It's all automated and like you,
you just take the command you get to release that you can
deploy wherever you want taking this.
Stuff and make it really easy to.
Use and and accessible was was a really, really big merit of of
Elixir and yeah. Yeah, and the tooling just works
well. Test like the testing suite like
is amazing. I like it.
I what's funny is with Killswitch, I've been writing a
lot more JavaScript because I'm doing a lot of client side
things like encrypting before uploading.
And so I had to go back and remind like I had to start
JavaScript, like writing unit tests and stuff and integration
tests for JavaScript. And you forget how nice like
writing tests and just like the output of Elixir tests.
It's it's like night and day compared to other languages too,
yeah. Yeah, it really is.
I think X. Unit is really simple.
It's really straightforward is but this, this is true about
many things, I guess in, in Elixir.
And one of the merits of the language and also one thing
which I guess allowed me to, to pick it as a technology to build
companies on is that no one, or at least really, really few
people in the team came with the Lex Bureau experience, right?
So most of the developers I have on the team and I had on the on
previous team in other companies where I, I, I made the same
choice. A lot of these people came from
random backgrounds, like, I don't know, C++ or PHP or Askel
or all kind of languages. And in my experience, the great
thing about the Lexi is that up to some level of complexity, up
to some extent, picking up the language is really easy.
So. So if you are a software
engineer, you will pick up the language in a really short time.
And that's amazing. That's great because.
Yeah. I I'm curious.
With your like current hiring practices, do you aim for Elixir
engineers or do you not really care as long as they have like
decent software experience Not. Not really.
So yeah, that's. Awesome.
Yeah, of course it's, it's also a practical reason like it's
really might be difficult to find a lot of people with deeper
elixir experience, especially in Italy which is a smaller market,
but. Also I guess.
It was just a choice because I'm not really interested in hiring
people with X years of experience in technology.
Why? I don't think that's a good way
to so because of what I said earlier.
So if engineering is a creative job, and if your job is building
an understanding of the problem and building a solution, I want
someone who is willing to learn new stuff, right?
So if. Someone says, no, I I don't want
to learn a lexer or I don't want to learn any other thing.
By the way, it's not just necessarily lexer, but if
someone says that, it's a big red flag for me.
Oh, for sure. Not because of a lexer.
Yeah, so. So the the the interview.
Process, for example, the technical interview process that
I came up with is starts from people's experience.
So if I interview you, I will ask, tell me about something
that you built that you find particularly interesting, right?
You, you pick what you built and, and you and you tell me.
And then I will ask questions and try to understand exactly
what you built and know it was and maybe we can reason about
it. And then from there, maybe we
can move to more, maybe. Theory.
Maybe we. Can get into functional
programming, maybe we can get into these things, but the the
point for me is not that you demonstrate to me your ability
to code in a specific language, the the point for me is that I
can. Reason together.
With you about the problem and and see how you go through some
kind of engineering program. Yeah, you want to be.
Willing. To learn new things and you want
to see how they solve problems. And the language is kind of the
last thing because if you can program, you can, you can learn
syntax and learn a new language, you know, so and you probably,
you probably want to see excitement behind a project that
they built too from the ground up.
Like if you're not excited walking through one of your
projects you just built like, come on, man.
Yeah, yeah, absolutely. Exactly.
I mean, so you're an engineer. So if you're not excited about
building and about learning a new language, what are we
talking about? Right.
I remember I like was. Interviewing like over a year
ago now, but I'm pretty sure, like, that was one of the
reasons I got the job is they're like, can you walk us through
like a side project? And I walked them through a
website hosting platform that I built with like, some dynamic
live view routing. And like, I was stoked about it.
And I went through it like, like, I was stoked.
And I think they enjoyed seeing that.
Yeah. Yeah.
Absolutely. So they're like, OK, he actually
built this. And he's excited about it and
can talk about it. Yeah, I.
Guess especially especially. In a start up, because it's not
like a job where you're working and you have all your little
tasks that you need to do that day and someone decided what you
need to do and you just fill in the blanks, right?
It's, it's more of a of the context where you need to
understand problems and then propose solutions, implement
solutions, build stuff. And so if you have no, no
enthusiasm for this, it's going to be really, really, really,
really hard to do. Yeah.
So. In your last like 4 years as as
sea bells been growing, what was like the most unexpected problem
that you had to solve? Like did you have any like kind
of like out of left field issues that created a more creative
solution? The most unexpected, I'm not
sure. So the, the most problematic
things we work with are external integrations for like the nature
of The thing is that you, you work with, with unreliable
stuff, right? So, but you somehow need to make
it reliable. Or maybe sometimes you work with
stuff which is not built to be integrated.
So initially when we started out, for example, the electronic
invoicing system didn't have AP is.
Today it has AP is and you can integrate with it and, and
access data. But in the, in the beginning it
had, it didn't have those. And so you had to somehow
simulate the user interacting with the the website, right?
And that's not great. I mean that that's not clean and
that's not exactly what you're supposed to do, but but it's, it
was necessary and you needed to solve that problem.
And so you you have to build it. And so you build some kind of
scraper which simulates the user logging into the website and
then acquiring the credentials and then scraping data from the
website because that's the only way you are going to get data,
right. So you need, you need to get
creative sometimes to, to solve to solve problems.
And yeah, most of these, I guess because the technical part was
quite straightforward They. Say.
And also thanks to Alex here, I guess because I mean, most of
the time we're just building crud.
Apps, right? Like with facelifts, and I mean
for the most part, like a web app is just reading and writing
to a database. Yeah, and up.
Up to a point until. Until you realize that, for
example, we have search indexes and we need to keep them updated
and we have data constantly coming in.
And so at some point you eat the, the ceiling of what you can
do with just a simple crab up, right?
But, but it's all engineering. So you start, you start
introducing cues, you start introducing the synchronous
stuff, you start making the system more complicated to to
adjust the new the new reality. I think most of the problems
come when you need to integrate with stuff which is not built
for integration. Or for example, another thing
that is problematic for us is accounting software.
Companies have accounting software which is needed to for
them to keep track of everything and they need to somehow get
their data. And ledgers, yeah, but
surprisingly. Like the vast majority of
companies in Italy still use on premises accounting software,
which was which is from 20 years ago, right?
And so you have a computer in a closet at in the office of your
customer and they somehow expect that you are able to integrate
this with, with the stuff, right?
And it's not so easy. It's not, it's not so so
straightforward to to do. Yeah, that, that's it I guess.
How do you? How do you?
Handle. How do you handle?
Custom integrations like that to stay in a profitable position.
Like if someone has some custom Ledger solution like, yeah,
sure, you can take their database data, but that's not
necessarily the easiest thing to like port to your tables.
No, we. We aren't we.
Aren't because. It's not possible or
sustainable, especially because as I said, our customers have
small and medium businesses and so they're not paying as huge
amounts of money for the service.
So we are not able to do that. And it's also most of the time
unreliable and difficult to do that kind of integration.
So in in reality, what we're doing is starting to build an
alternative because we already have all the data that an
accounting system needs. And so we want to also take the
accountants and bring them on the platform to work live
together with users to do the accounting part, which is
something that we have have not done up to up to now.
I feel like that's a smart move. And then you.
Kind of you're you're you're kind of just turning into that
one stop shop, right? You're just a solution for small
business at that point. Yeah, absolutely.
Also because. At least in Italy, accounting
software is produced by a number of incumbents which have the
majority of the market. And of course they are not
helping us integrating with their software, right?
Of course, so and so you, you need to find a way to to to go
around this and integrating with with on premises custom
software, legacy software from 30 years ago is not going to be
feasible, right? Well, you're still going to like
even. Once you have the solution,
you'll still have to deal with the problem of migrating from
other platforms, right? Absolutely.
I'm not. Saying that it is.
Not technically doable. It is technically doable, but it
will somehow be really difficult to manage.
And so it will be a huge operating cost.
So you will have to have people managing the process of
migrating customers from one thing to the other, of
connecting stuff of making sure it works.
So everything that's really, really complicated and the, the
like the economics for this don't work in a SAS model,
right? So you are not selling, you'd be
selling like consultancy or services, right, Not the SAS
business. Yeah, yeah, Yeah.
Well, I mean. I guess you can just find
someone and turn them into a consultant, right?
And then they can help people migrate to your platform.
Yeah, yeah. One one thing you can do.
This is by and those incumbents do this actually is partnering
with with system integrators so that they have a huge network of
system integrators that also act like resellers up to a point
because they also sell their solutions absolutely.
But I guess it's. A different model, right?
And maybe we are. Challenging this model so.
We are saying instead of paying thousands of EUR each year for,
for the software and the services that you get from these
kind of players, you could buy a subscriptions to our, to our
service, which is all in the cloud.
And, and you can also you, you don't need to operate it.
You don't need the computer in the closet.
You don't need anything on premise.
You, you just need to to pay for the services.
You get everything. And also you get a different
user experience because the, the point is also that this kind of
software is really from, from a different age.
If you if you look at it, it's yeah, it's kind of wild to
think. All the small businesses that
would host servers in their in their office.
Space. And have to maintain those and
have a database and because I grew up in a small business, a
small family business and that's what we did.
We had a server that we barely knew how it worked and it took
care of all of our our invoicing, everything.
It was kind of wild to think about.
Yeah, absolutely. And you?
Yeah, you have maybe some kind of computer guy which maintains
it and makes it work, but I mean computer.
Guy like I sometimes wore that hat.
It didn't. It didn't go well.
Who hasn't? I mean like part.
Of me misses those days because you didn't have recurring
subscription costs for everything.
But then like part of me, it's kind of nice just to have a
service that works and it's easy you.
Can access it from almost. Any device that has access to
the Internet. And that's pretty cool.
Yeah, it's easy. For example one.
Of the fears of of people running, for example, accounting
shops is that they know they have this server in their office
which is necessary to in order to run the the business.
And maybe they also perceive somehow that it is a problem,
but also they are worried about losing the data.
So they are somehow reassured by the fact that all their data,
all their customers data is there in a physical place next
to to where they work and when you try.
To sell them the. Disaster model where you the
data is in the cloud and of course it's their data, but it's
not on premises. It's kind of hard to to convince
them. There's something reassuring
about having your own machines and your own data where you
where you have your office. It is, especially if you know
you're doing the. Backups and things.
Then you, you know, you know you have it, right.
No, no, of course there's no technical.
Reason because of course we can guarantee I mean, but better up
times and better security and better backups and whatever you
you will get from a server in a in a closet with no, no UPS and
no no backup Internet connectivity.
But yeah, somehow there's still something assuring for them in
in having their their own hardware and being able to, I
feel like a lot of like the older.
Generation, too, before SAS became a thing, it was like you
bought physical copies and versions of software, and they
just liked knowing that that was theirs.
And no one can turn it off, you know?
Yeah, yeah. Yeah, I remember it.
I remember the box and copies of software on the Chevy.
So I just like floppies. Zip.
Disks and tons of cd-roms. Yeah, I think I had the.
I had a copy of Windows 95, of the Windows 95 installer on 25
floppy disks. Oh my gosh, that's wild.
Yeah, and. And the 16th was.
Was bad for some reason and so it's never I never actually
managed to install it all because you had to change the
floppies and and the 16th floppy was was yeah like so like.
A. MB and 1/2 right?
And you have to just keep moving your floppies in and out.
I don't miss those days. No, no, me too.
Me too. Yeah, and now look.
At the cool stuff we can Do, we don't.
Really have to worry about limited resources.
We just can add more RAM to things and go, yeah, that's true
in a way. It is also true that then you
have. For example we have had in the
past couple of years down times due to AWS outages due to
Cloudflare, Cloudflare outages. Cloudflare was a bad one.
This in the. Like a couple months ago
exactly. And.
So you kind of you, you still kind of depend from this
infrastructure to to work. And so it's not necessarily
always a good thing, but for sure access to to sophisticated
tools is way better now. So yeah, it's, it's convenient.
I mean, you, you can spin up a lot of stuff from just just from
from the comfort of your office or your house.
And I, I remember the days when I had to drive to, to the data
centre to, to install new Ardo. That's wild.
Yeah, that's that's. Because at the.
Time. You didn't have any other way to
do it, right? Dang, that's.
Crazy, I've never experienced that, but yeah, that like I have
to go drive to the data centre, got a deployment to do, I took
my bike, went there and. That's awesome.
It, it was normal and of of course, today, today is it is
much more convenient and and it's incredible what you can
build just with the credit card and I I think like.
That's probably one of my favorite things and what got me
into software development. Like look at what we can build
from just an investment of a computer.
Like that's all you need. You don't even need a server
because you can rent space on someone else's server, you know,
and you can deploy an entire product.
And I think that's really cool. That's great.
At the same time, I think it's also the source of many
challenges. So what you were saying earlier
about being conscious of security, of privacy issues,
because it's so easy, so easy to build something, to deploy it to
vibe code something and throw it on the Internet.
That of course that there's also a lot of risk involved, right?
Because then then you have security and you have privacy
and you have a lot of other things that are not necessarily
so, so straightforward. And, and that's why I'm not
worried about losing my job or about engineers losing their
job. I yeah, I don't.
I don't worry about that either. Like I see tooling that's
getting really good, right? But there are you still need the
experience and a lot of like. The planning and.
The ability to architect and the ability to know when something's
not right, because otherwise nothing's correcting an LLM when
it's spitting out bad information or hallucinating,
right? Something has to correct that
path, and we're definitely not there yet, yeah.
And and we, we are that. We might be getting choppy.
Again. Oh, you're back.
All right. OK, so.
No, you're good. We, we are the ones.
Who need? To to to somehow guide the
process. Yeah, exactly.
And like I know. Like I.
Think, you know, what we do today is going to probably be
vastly different in five years from now, even probably a year
from now, but the engineer is still going to exist.
We're just going to be able to do a lot of a lot more as a
single person, yeah. Yeah, absolutely.
But I think this. Is like not so different from
what happened in the past. So as I was saying, so I, I
don't need to drive to the data center anymore, right?
And it's the same thing like I did because there was no, no
other option if I wanted to, to set up a new server.
And now I don't have to, right? So yeah, things have improved.
Things have changed and I, I think like AI is, is doing the
same thing in a different way. It is really commoditizing the
production of, of software and the, the product, the act of
writing code. But I never, I never thought of
myself when I I was a coder and I coded all day.
Still, when I when I do it, I never thought that my job was
writing the code. I thought that my job was
building a solution for something.
Your job is solving a problem. Yeah, absolutely.
Yeah, it is. It is solving a problem.
It is not writing the code like writing the code is the, the,
the medium I, I, I need at the moment, the tool I need to do to
to do what I need to do. But what I need to do is
building something. Yeah.
And I think that's the perspective.
That people need because I feel like there's I, you know, you
have your software engineers that are like gun ho AI and then
you have the holdouts that don't like it at all.
And like, I kind of get where they're coming from, but I do
think they're more focused on thinking that they're a software
engineer because they physically write lines of code.
And that's that's not, that's not what makes them a good
engineer. No, absolutely.
And also I think that. Maybe a lot of the narrative
about software engineering being bad and about engineers losing
their jobs is coming from the same people selling the
solution. Of course, you know, yeah,
they're, they're over hyping it, you know.
Well, like I have a couple friends in my life that are not
technical people and they're trying to like write apps and
like make solutions for their like day job, right?
And some of the things that they they ask me about or are telling
me that they're doing and trusting to AI, our jobs are.
Secure for a very long time. Because they're doing some very
scary things and just trusting and they like, they don't know
what environment variables are, they don't know what git is,
They don't know what a lot of things are and like, which is
fine, they can learn. And I do think AI is a great
tool to help you learn. But if you're just vibe coding
with it every day and not using it to learn as well, I don't
think you're going to benefit much.
Yeah. I think it will be interesting
to. To see what happens because me
and and you we we grew up from a different perspective right.
We we needed to learn to code and then we are looking at AI
doing some of these for us. I I'm extremely curious of
seeing someone starting today what what is perspective will be
yeah at at some point. So, so how, how will it work?
Because at the same time I can, I can say that learning for me,
especially at the beginning in the 90s, it was painful because
you didn't have a lot of information because you needed,
so it, it was way more painful. You needed physical books back
then. Yeah, absolutely.
I still do because I love books. But yeah, I mean, it, it was
really hard to to, to gather information and then to acquire
knowledge and then to be able to produce something.
And, and you needed to experiment a lot.
But that's also what allowed me to learn a lot of stuff.
And I'm, I'm not sure I, I think the same thing in, in some form
will happen with, with the with the AI and with these tools and
for people starting right now. But I think yeah, yeah, people
are going to just have different pain.
Points of learning, right? Like, yeah, they can ask an LLM
something, it'll answer them. But now they're going to run
into problems where they might not know how DevOps works, and
they could have security vulnerabilities and they're
going to have these. They're going to have pain
points that they have to still work through and learn, you
know? Yeah, I guess.
That well. Maybe it won't be so different
because I was like my my frustration with the with the
compiler of the computer telling me that I was wrong.
It will be the new frustration with the LLM not telling you the
truth or making stuff up. Exactly.
So maybe it won't be so different.
At all? Yeah, exactly.
No, like I know like there's some like doom and gloom with
like being a junior or being really new to programming right
now. And I want to stay optimistic on
that end too, because I, there is parts of me that are worried
because I feel like a lot of engineering positions, everyone
wants seniors now and they want to just like leverage AI with
senior knowledge, right? But I still think there's space
for juniors because you can just get up to speed so much faster.
Like, even if you just need like a, a ticket puncher on your code
base, like a junior is perfect with that, like a like give them
some good AI tooling and you know, some guidance like PR
review and like senior engineers that are working around them.
They can be a good ticket puncher.
They can fix a lot of bugs in the code, you know, so I think
there's still, there's still going to be a lot of
opportunities for new people. Absolutely, absolutely.
And that's. Why?
I think you need a great, like you need a great culture too to
to do that, though, you, you need a system where people
understand that you need people at different level of levels of
experience. And you need to, to, to nurture
the culture where, where you have a system where you care
about quality somehow, right. So this doesn't mean that you
can't use AI. You can use AI, but you also
need systems in place to make AI work.
And at the same time, you need inevitably you will need to have
younger people at some point, right?
We, we can't just or or I don't know.
So if you remove young people at some point, you will only only
have a senile program or not. Well, that's the yeah, that's.
The big problem, right, Like if you don't hire young people,
then you're only going to have greybeards, and then greybeards
retire, and then what? Yeah, yeah, yeah, yeah.
And and then who does it right? Who will be the so who will will
be the next wave of of computer engineers exactly You need them.
Yeah. So I think we as long as we keep
that. In mind and I think that's the
maybe a problem with like less technical founders that have a
tech company. If they don't see that and they
just want, you know, smart senior level engineers that can
just knock things out. I feel like you're not thinking
about the full problem because we're all going to be in a
position where you need to replace your older developers
when they retire, they move on. Like another huge concern,
especially with LMS. If you just have senior level engineers,
they're going to start building their own products and might be
successful on their own and then leave.
And then you need to be able to replace them.
And hopefully you had some under them that they were kind of
training. So I think we have to just kind
of, we got to keep this in mind just as if you're a founder or
anything involved in tech. Yeah, yeah.
Absolutely. At least if you are.
In it for for the for the long game, Yeah.
If you're playing the long game, then then you need to worry
about this. I don't know my my impression is
that. Everything is.
Getting real fast, really fast and always it's always faster in
this industry and and I don't know, I don't know how many
companies really are there for the long run there for, for
building something that lasts. So maybe also this, this kind of
view of things is, is a bit of view of the it's, it's the past,
right? Like now you build the company
very quick, you sell it, you're done and then on to something
else. Yeah, yeah.
I wish I knew so building. A culture can.
Be challenging. I think it can for sure.
What is? Your kind of take like you know,
you said you had 40 engineers or just 40 people at the company.
No, the company is. Over 100 right now, OK.
We have. 25 engineers, we have software engineers, then we have
four people doing operations and systems engineering
infrastructure. We have designers, 6 designers
and then some people doing also tech support which is most more
Technical Support for users when they encounter issues.
So I'm curious. What is your?
Approach to like hiring junior levels to senior engineers?
Like kind of do you hire juniors?
Yeah, more. Recently, yeah.
So the challenge with hiring junior people at an early stage
in a startup is that you don't have the resources and time to,
to grow them, right? Because you, you, you can hire
juniors, but you also need someone who mentors them,
someone who helps them grow and who directs them in a way.
And so up to, for, for the first three years, we, we couldn't
really afford to, to have, to have a lot of juniors.
And slowly we are starting to, to do that.
So we, we are starting to hire people with less experience than
than before. That's awesome.
I I do think. Like it's very difficult.
You can't really hire juniors at the beginning because you need,
you need as much resources and fast-paced movement and features
as you can. And you need things architected
well 'cause everything's brand new when you're kind of
bootstrapped at the beginning. But yeah, as you grow, that
makes sense. You can start hiring juniors and
I think that that's, that's awesome.
Yeah. So I.
Mean for the. First two years, the engineering
team was for people plus me, right?
Yeah. So those first four people, they
were all really experienced. But it's it's inevitable.
I think it's yeah, for sure. Awesome.
Well, I think. I think these always go by real
fast. We've been talking for over an
hour and a half, so I think we can wrap this up.
I really appreciate you coming and chatting, Luca.
It's been awesome. If you want, is there any advice
that you want to throw out there before we completely sign off
for the week? It's been a.
Great pleasure for me too. Jacob, thank you.
Thanks for having me Advice. No, I don't have advice.
No advice? No.
What? What kind of advice do you have?
Any advice for maybe junior? Developers or somebody that
might want to be a Co founder or like ACTO in your position.
Any any advice in that kind of direction, career career
direction. I, I don't know, I think.
My advice is what? What paid off for me was
following my own curiosity and experimenting a lot.
And so, yeah, I think if you want to have a career in tech,
if you want to grow as an engineer, if you want to find
out what what clicks for you, you need to do a lot of
different things. And you need to also do a lot of
mistakes. And I think without that
enthusiasm, you are not getting anywhere.
So, yeah, so my, my advice for anyone was to get in the
industry despite AI is just follow your instinct, learn what
you want to learn, what excites you, what, what really you, you,
you have a deep desire to build and, and go do it and learn from
that experience. And yeah, that, that works for
me. I, I think that's amazing, I
think. That's great advice and the kind
of not to keep us going. But when you were saying that,
you know, you implemented your Http://library, right, and you
wanted to implement HTTP 3, but it was a lot more complicated,
but like just building that project probably allowed you to
have so much more understanding because you just dove in and
started doing it. Absolutely.
My my. Objective was not to build a
real implementation. My objective was learning and,
and I did it by by sharing enthusiasm and, and wanting to
learn and, and to to be able to tell.
OK, I understand this because I built it, right.
And that's exactly what I meant. It's.
Yeah. And that's what exciting for me.
But if anyone is excited about anything else, they should
absolutely go and build it because.
Yeah, that's great. Yeah.
I love it. All right.
Awesome. Well, thank.
You so much and everyone that tuned in.
Thank you. Have a great weekend and I will
see you guys next week.