00:00:10.519
okay uh hello ruko um so welcome to the history of a
00:00:16.160
rails monolith uh let me introduce ourselves uh he's an atol uh my name is
00:00:22.359
Christian and we both work at zesk we've been here for quite a long time uh and
00:00:27.880
yes everybody's asking me the same if is zenes using rails yes the main product of zenes has been using rails since the
00:00:35.160
beginning it's actually a rails monolith so yeah we use uh Ruby and rails very heavily you know in our
00:00:43.680
structure doesn't work like
00:00:50.760
this um said this this is a presentation about the history not only about this monolith but about the whole history of
00:00:57.480
Ruby and rails at least for the last 17 years uh but most importantly I want you
00:01:03.960
to understand that how special we are as a community you know like we are we are different from all other programming
00:01:10.920
communities in the world I would say and let me give you a an ex I would say that
00:01:16.799
our history is amazing and I will give you a bit of a crazy example you know this movie
00:01:23.000
Gladiator 2 I am incredibly excited about it it's going to be in a few months released I mean I I'm looking
00:01:29.680
forward for it said this everybody saying the same it looks good the trailer is fine but you know they had to
00:01:35.600
made up stuff somehow looks like the Roman Empire didn't have enough drama to
00:01:41.240
make a movie about it but this is actually H something that happens very often like in this other
00:01:47.759
movie Napoleon they also had to make stuff apparently you know like the Napoleonic wars were not exciting
00:01:53.719
enough do you know which movie didn't need to make up anything to have drama
00:01:58.759
conflict or all kinds of crazy
00:02:05.759
stuff I mean I mean you you know this you've been for a while in this community you know that like we are the
00:02:12.560
the the community of drama it's there's so much like this is just something I took in five minutes yeah remembering
00:02:17.720
stuff that happened for us and don't get me wrong I absolutely love the drama
00:02:23.519
it's like it's hugely entertain entertaining it's not like it's not only have a job it's like I have a job in the middle of a soap opera it's fantastic
00:02:30.680
uh for a while actually I tried to become a Scala developer and that was very long three months um but uh I went
00:02:39.080
to a to a conference actually no I think was Scala by the way scale by the way and I was a bit shocked because
00:02:46.080
everybody was dressing like this as you see speakers inie conference don't dress
00:02:51.120
like this and they were you know talking very corporate about very corporate
00:02:56.480
stuff few months after I went to Rubicon
00:03:02.400
and this is who gave the who gave the keynote so yeah we are we are different
00:03:09.440
and different in this case makes makes us better I would say um I I I would like to finish this
00:03:16.280
part with saying with commenting about something that uh Jose valin said commented the other day which incredibly
00:03:22.239
inspired me is this like being passionate about technology is something I learned from
00:03:28.080
the Ruby community um actually it I also learned it from the community so thank
00:03:35.159
you okay but let's get into the topic uh we're going to talk about the history of AR monolith and why I feel like talking
00:03:42.120
about this now well uh I recently moved back to my hometown Barcelona I lived abroad for quite a lot of
00:03:48.799
years and at the same time I made my 10th anniversary working at zesk which is quite a lot of
00:03:54.760
time and finally I don't know if you anybody here knows about this TV show
00:03:59.840
but have you heard of this TW show called Fen knows okay so
00:04:06.920
um f is a show that follows certain tradition uh
00:04:12.319
yep follows a certain tradition of fantasy fantasy it can be understood to
00:04:18.000
talk also about technology you know it's like the the linking between science fiction and and fantasy uh one of my
00:04:24.479
favorite examples is uh a wizard oversea bya lein and in a wizard of C magic
00:04:30.919
Works in a very specific way you can control something if you know its true name honestly for me it was always
00:04:37.000
always felt like it this about abstractions you build the right abstraction about a on a system you get
00:04:42.639
power over it but again I didn't I didn't create this this leing between technology and and Magic this is
00:04:49.280
something that has happened always so what does fan say about about magic SL
00:04:55.080
technology well the plot is is like that you have this elf who is kind of immortal
00:05:00.360
and you see her through multiple centuries so well you see her like having friends friends die because most
00:05:06.880
of the people are humans in this world uh but you also see how magic evolves for example a a spell that is something
00:05:13.479
incredibly Innovative in the first part let's say becomes the the Cornerstone of all magic in the future I think a little
00:05:20.000
bit that technology works in the same way moreover I kind of started to identify a bit like like freen with
00:05:27.120
freen um I mean she is an elf that has lived over over a thousand
00:05:33.840
years and that makes her the the possessor of Forgotten forbidden magical
00:05:41.720
knowledge okay what what about us I would say that we that Anatoli here
00:05:48.840
and me uh we are equally mythical we are Engineers that have been over 10 years in a big tech company
00:05:56.400
doing rails this makes us the possess sort of Forgotten forbidden magical race
00:06:03.199
knowledge and we would like to share it with you okay let's let's start on on the
00:06:09.039
topic itself I want to talk a bit about the history of the concept of monolith and how it evolved in the last 17
00:06:14.440
years um you know I started my career in late 2000s you know those were the the
00:06:19.840
good times uh but you know then started the 20110 no and the 20 we did all we
00:06:25.280
all of us did all all kind of weird stuff um but uh and this may or may not
00:06:31.520
include uh microservices no uh I am again something I'm going to repeat a lot of times is that I'm not against the
00:06:38.160
idea of microservices per se I am just against the idea of using microservices
00:06:43.520
everywhere all the time without any reasoning um the good news for me in my
00:06:51.240
opinion is that monolith are back uh I think in the last few years since the 2020s I would say uh this idea came back
00:06:57.759
and became more popular honestly if you've been a while in the industry you realize that a lot of these debates are
00:07:03.120
pendular you know opinions move back and forth sometimes with a lot of a very clear clear reason beyond the
00:07:10.120
idea that you know the Grass Is Always Greener in the other side a lot of these debates are about trade-offs and suddenly it's very easy to forget about
00:07:16.919
the bad part of the trade-off that you just did or the but then this leaves us with a
00:07:23.879
question why why the microservice womb why were they were so popular in the 20110 well this idea that has been
00:07:28.960
repeated a bit in the last in the last talks but uh I think that the zero
00:07:34.039
interest rate may have may be a part of it you know there were so many money in the market that a lot of the bad parts
00:07:41.599
of microservices like the high complexity to maintain them uh became more acceptable but again uh I am not
00:07:48.199
the only person that say this this conference I was very happy when I saw I saw this Slide the other
00:07:53.879
day uh but again microservices have uh what happened with microservices during the last decade was absolutely really
00:07:59.919
crazy uh I remember I went to visit a friend in Montreal uh he was working for a startup and he told me the story he he
00:08:06.879
started to describe me the architecture of his of his uh of his company and it was this kind of incredibly complex
00:08:13.120
stuff you know like they had hundreds of microservices and I was like uh man I I really don't understand this design but
00:08:20.199
but congrats sounds like the company is doing well to maintain all this he told me no Christian we only we only have 10
00:08:26.319
customers uh and and this this this we we we all know that that that
00:08:34.399
happened um say this I am not totally against the concept of microservice I wouldn't dream to write that it's bloww
00:08:41.240
as elen Elon did here my my opinion is more similar to Jason Warner uh the CTO
00:08:47.240
of GitHub that this is like a spectrum and a lot of times when you start a
00:08:52.279
company startup you want to start with something that you know you're able to iterate very fast and in my opinion m
00:08:59.600
are great for this when you're searching uh Market fit then it's great and then slowly you can you know break this
00:09:05.920
monolith and and and make Services if you want this is kind of the path that
00:09:11.800
Zen has been following in the last 17 years even if I don't think there was out of times a very clear direction that
00:09:18.399
that's what we want to do but that's what we end up doing said this we there was multiple phases during the 70 years
00:09:25.279
the original Vision was to have a set of rail apps that they will share a significant amount of logic so yes we
00:09:31.040
will grow we will have different applications doing different things but they would share uh code they would share libraries where most of the code
00:09:37.760
would be there uh this Vision lasted for quite a long but we are not following it anymore but said this you can still see
00:09:44.920
a lot like the remains on the on the Jame file all these zore gems are stuff
00:09:51.640
that live in our monolith and they are shared by a very very few applications but you know they are there
00:09:59.440
then later we move to what I call uh the service data and uh in our case I don't
00:10:05.279
think it was so much uh the because we wanted to follow change our architecture
00:10:10.360
but it was more because we made we bought companies we made Acquisitions and it made sense naturally
00:10:16.480
to build services to share information in between two different applications if you have application a and application B
00:10:22.519
it doesn't make sense that all the information for accounts live in a it's kind of arbitrary
00:10:29.800
finally uh we moveed where that what we're doing more and more is uh event driven architecture so using uh Kafka
00:10:35.920
for example we generate events and uh those events are consumed
00:10:41.240
by other applications that at the same time do certain action generate other events and you know it's like a a pinball game in in the
00:10:49.600
end next anat will talk about how the database
00:10:57.839
evolved everybody my name is anol I work at zesk 9 and a half years I
00:11:03.519
think nine years so we went through uh uh Journey
00:11:08.600
from small startup to large Enterprise NC some friend in Auditorium his name is
00:11:14.959
Casio he was part of Zen desk fantastic engineer say hi to
00:11:21.000
him did that make it right any I didn't start as Ruby engineer I
00:11:26.560
started as C admin and I see another friend in the room Ivanka is he is he
00:11:33.560
here he's probably I see he fantastic okay I made all my homework right okay I
00:11:41.040
started as this admin and I was not interested in development up until 2007 so and all my like experience at
00:11:48.800
Zen desk gravitated towards operational reliability work this how I end
00:11:54.519
up in where I am and I took the uh two
00:11:59.600
months ago I talked to my friend about Ruby performance and reliability
00:12:05.800
and why people think that Ruby is slow I think you know my friend does anybody know my
00:12:11.200
friend somebody of you know my friend so we talk about performance of the systems
00:12:17.680
and particular large system performance and you ask me and what M has to do with
00:12:23.720
the databases quite a lot let me explain zers is large organization very
00:12:30.639
large organization and large organization have large data set and I can tell that
00:12:37.839
database is the biggest bottleneck rubby has never been bottleneck what happened is databases
00:12:46.160
zendesk is not a single server of course databases zendesk is a shared it's uh shed database
00:12:54.480
infrastructure with many more servers than you can fit in your head with the same schema and a shing key is account
00:13:01.399
we have bunch of customers in one chart another bunch of customers elsewhere
00:13:07.160
Etc that tells you one thing that we don't keep all data in one place we keep it in multiple
00:13:13.279
places was it enough no it wasn't what happened is we found out
00:13:19.600
that we have a clear distinction between active data and non-active data you can have you can say cold and hot storage
00:13:27.000
active passive whatever you call it but
00:13:32.519
my microphone t t can you hear me I have a backup backup microphone is
00:13:39.760
amazing so we we have a clear distinction between active data set and non-active data set was it enough no it
00:13:47.800
wasn't the picture you see on the screen is very important to understand where we are and why Ruby is not slow why
00:13:55.320
something else is so we have data archived to go to
00:14:00.880
Dynam DB and elsewhere and the message I want to share with you is left story from book
00:14:07.680
called anakar said all happy families are alike each unhappy family is unhappy in
00:14:14.040
its own way and I can say that all happy systems are alike each unhappy system is
00:14:20.279
unhappy in its own way what makes your system happy what makes your system
00:14:26.000
unhappy and you can guess that I talk about database all the time so it will be about
00:14:31.240
database three properties about good
00:14:36.680
database uh you expect database to be performant and fast you expect data
00:14:42.480
database to handle any query active record can throw with it
00:14:47.560
and you expect database can have any data you want well a lot of physics tells that
00:14:55.040
memory is limited you can't you can't fit everything in memory even if you can you can only choose two out of three you
00:15:02.160
cannot have three together and this is the story of Z that's how we went through transition and fix many
00:15:10.519
problems you can have two out of three which two past of Z desk small data set data
00:15:19.000
set was relatively small to where we are today query run time was consistent and
00:15:24.880
we can do anything you can run any query with active record you'll notice the
00:15:31.480
difference next slide I call Crisis crisis in data set became too
00:15:37.839
large even if you archive even if you share database it doesn't matter if you
00:15:43.319
hit certain size of the organization and the an amount of customers and
00:15:49.440
users what has to take at back seat Well very run time I took a back
00:15:55.720
seat complex queries dominated and the data set expanded so much so quick it
00:16:00.920
followed exponential grow curve well this is the present present
00:16:06.319
is large data set is still large data set it hasn't gone anywhere but the
00:16:12.160
query run time approved and you can guess that the message I come back again and again that
00:16:18.560
the performance system large system equals large data
00:16:24.680
set that means that the data set has to be manageable for the queries you ask it
00:16:31.839
to do and if you know about am the law you know that the if you have no data if you have a
00:16:39.000
basically a stateless system you can scale as much as you want you have like
00:16:44.160
you throw more Hardware you have expected consistency in run time small
00:16:50.279
data set follows slightly worse suboptimal curve but large data set hits certain point can't have Mouse pointer
00:16:58.279
but uh when we hit a certain point of the degradation nothing will
00:17:03.400
help only thing you have to do is to go back and use the data set to be on
00:17:09.959
thecore and I I have something to ask you I'll tell that uh Ruby is not slow
00:17:18.640
what is slow and you tell me database ready Ruby is not slow what is
00:17:25.160
slow okay that's it okay
00:17:30.200
your database will become bottleneck long before the Ruby will and that's what the message I want you to leave
00:17:35.360
with back to Christ yeah thank you natal and next I
00:17:41.720
would like to discuss a bit about uh something that is super important uh to keep a healthy business you need to test
00:17:48.640
stuff please don't do something like this uh I was you you know about what
00:17:53.760
I'm talking about no like a few months ago apparently someone decided to deploy a change antivirus that was modifying
00:18:01.039
Windows kernel without testing anything so he broke basically all the windows machines in the world thanks God I don't
00:18:06.640
use Windows but still I don't use Windows but I still miss my flight to Singapore thanks to this so thank you uh
00:18:13.039
so don't be like this uh but going to uh a bit deeper into this I would like to to comment on a conflict that there is
00:18:20.600
in software engineering particular in dynamic in dyamic languag I would say is test versus types uh the original uh
00:18:29.159
well the value proposal in rails is that well Ruby is that you don't really need
00:18:34.520
types because you need test and if you have enough test then you probably you don't need types of course there is a
00:18:40.200
lot of debate about that a lot of people are using svet things like svet um but
00:18:45.760
at zesk we are very extremely in the left side of this debate we we have experimented with a lot of stuff not
00:18:51.960
with not not really with typing uh still we need to have a lot of test because we
00:18:57.480
do have a lot of code like over 1.6 million lines of code uh in the MTH and
00:19:02.600
all the gems that we are including that is part of libraries like private to zesk and how many tests we have to test
00:19:08.880
all these all these things so I counted a few months ago and I I this is the number 55,0 786 tests actually we do
00:19:17.559
have way more because this again does not include the unit test that belong to this private
00:19:23.240
gems uh so you will be thinking okay how Christian how do you manage all these Madness because there is a lot of test
00:19:29.720
that all these are all this is being run every time that someone does push so how you manage this well we have a secret
00:19:37.440
weapon uh a strong Guardian that checks the the value of our code and checks
00:19:43.159
that everything makes sense and is correctly tested his name you may some of you may know him he's called Ryan
00:19:49.240
Davis uh Ryan Davis is actually the Creator and maintainer of mini test and this Avatar is his real Avatar in the
00:19:55.679
slack the slack let me merch or I will right um sometimes I I I like to to help
00:20:02.720
Juniors and sometimes they come to me say hey Christian you know remember that P I wanted to merge it but I was not
00:20:08.840
able there is this guy that is telling me to add more tests it's like oh you met you met Ryan that's great so again
00:20:16.760
uh at attendance we have the creator of mini test and we use mini test very heavily and at this point you will be
00:20:22.960
making the same question that a lot of people that join zes does why mini test
00:20:28.000
and by that they mean why not the other testing library that is very popular in the Ruby World well we do have a reason
00:20:34.880
I would say again the context here is that we do have a lot of test and we run
00:20:40.039
them a lot actually it's not like we run the whole test suite for each push we
00:20:45.159
run it twice there is a reason for this I will explain later uh that means that
00:20:51.280
we are running 111,000 572 tests so why is manyi test better in the in this
00:20:57.320
situation I have rant and he said mini test is fast small and less magic the
00:21:03.840
than the Alternatives in fact when we try to modify a little bit mini test for our own purposes what we do is reduce
00:21:10.799
features and have less magic we want more performance okay the the twin sister of
00:21:17.279
testing is reliability uh obviously this is very important we have customers and that's
00:21:22.679
where from where we make the living let's be honest we we all mess up from time we all end up in in stupid situ
00:21:29.600
that's normal but still we need to be very careful uh software has a real impact on the lives of on the lives of
00:21:36.240
people you know like for example the other day I was uh talking with some some Engineers I met like from a company
00:21:42.880
called called nepro uh and they actually doing uh software for dialysis patients
00:21:49.840
that's that's something that you can you cannot mess up here um still for most of us the real relability wise the moment
00:21:57.559
of truth is the deploy you can have a super broken branch in your side nobody
00:22:02.960
cares the moment it touches a a customer system then is when things get bad so as
00:22:10.480
we have a very very specific pipeline that you need to follow to deploy this
00:22:15.640
is uh how it works first we have a phase one in staging when we run a very heavy
00:22:20.840
test Suite of integration test both browser and API and then we give 50 minutes bake time 50 minutes is time
00:22:28.200
where we are not doing anything we expect the people deploying code to test manually but honestly a lot of people
00:22:34.919
lot of times there's no manual test there but sometimes things pop up like
00:22:40.600
sometimes there is processes that run once an hour and then that's why the catch the error that it's a it's a
00:22:46.559
useful practice moreover this is staging then we deploy into Canary Canary is a
00:22:51.600
production pot so it's a set of accounts but where we have mainly test accounts and other things no but mainly test
00:22:57.840
accounts here it we run a smaller test suit that is the same that will run in all the
00:23:03.200
pots and we live a longer a longer baking time just to make really really sure that nothing like a crown is is
00:23:09.880
breaking the system after that we run through all the all the faces with the
00:23:15.000
uh the same standard test Suite this actually important because sometimes you find backs that only happens in one pot
00:23:20.480
uh this is because uh some pots are Regional I remember once we had a back that was affecting only uh Ukrainian
00:23:26.440
accounts for because of certain things of with coding and we only found that in Phase five I think it was when we hit
00:23:32.960
the the European pots in total a deploy in classic of the monol takes around 3
00:23:38.840
hours still I would say the most important thing for us from a reliability perspective is the concept
00:23:44.159
of ownership um why well we have a lot of code a lot of codes means that
00:23:49.880
historically we have a lot of committers a lot of people push code into zendesk okay you may be thinking zenes has been
00:23:56.279
around for a long time like 17 years um maybe most of these people you know left the company and there's way less
00:24:02.760
people working in the mon now well not really only in the last 3665 days 570
00:24:10.360
different committers push code into into the main branch and this can be this can be
00:24:16.760
problematic uh you want to have a a good order to for this to make sense so it
00:24:22.799
doesn't end up in in a fight can end up in such a hellish fight as this AI image
00:24:28.760
you can see there you want to be able to uh Trace who did what and who is
00:24:34.840
responsible of what so we use code owners which is a feature I think in GitHub where all files needs to be owned
00:24:41.720
by one team this very useful not only about saying who who is responsible of this incident we we are our cure is not
00:24:48.120
like this but more of who is going to be working on a certain project or who can
00:24:53.760
help us when there is a problem thanks to this it becomes way way easier to track
00:25:00.000
finally and I'm getting to the end uh maybe the most important about a an application that has been using rail for
00:25:06.559
a lot of years 17 in our case is upgrading it so I will explain you some you know battle histories uh then
00:25:13.960
started with rails uh 1.0 and right now we are I honestly I should have checked I think I think we
00:25:20.399
are in 71 or 72 I I I don't I do not remember uh probably 71 um we upgraded
00:25:27.480
thanks to hon ly testing we have a lot of tests and having a lot of test and being able to run them against different
00:25:33.840
versions make us feel pretty safe when we move to to a new version um and actually this is why we
00:25:40.440
are running all the time not all the time but very often uh test against two different ra versions We execute test
00:25:47.159
against the current one the one is in production and against the next one that we want to move so imagine we are in
00:25:53.120
rail 7 70 we are going to be running test in 71 so 70 and 71
00:25:58.919
the idea here is to avoid regression so we have a team working on the upgrade you don't want that hey I fix this 1,000
00:26:05.360
test oh my God someone modified the file and broke them again once a a group of
00:26:10.520
test is green it can we it needs to stay green we can know we don't we don't
00:26:15.919
allow regression in that regard finally which one which one have been the the pain points of upgrading R
00:26:23.360
through so many versions well the next slide kind of HTS me because it's at technique that you used to adore and a
00:26:29.760
book I I love uh but honestly metaprogramming um if you've been around
00:26:36.919
a long time in Ruby you remember that 15 even 10 years ago metab was amazing was everybody was using it all the time it
00:26:43.159
was like monkey patch monkey patching stuff was super normal uh ghost methods
00:26:48.960
anybody remembers what is what were ghost methods well the problem is that when you have a huge application and you
00:26:54.760
need to maintain it and upgrade it this becomes like a huge a huge s pain for a
00:27:00.039
long time we kind of avoided that say okay you know you can monkey patch again this method so it works with rail 4
00:27:06.399
whatever until we got to rails five basically trying to upgrade from rails 4 to five broke all the test and we
00:27:12.880
weren't even sure why so at that point we decid to go hard mode and de said
00:27:18.520
let's remove all this magic let's make this code as simple as possible let's actually this was a bit LED also by Ryan
00:27:24.480
Davis uh let's try to make things as simple and straightforward as possible problem is that that upgrade
00:27:31.000
took us two years and a half was very very long this actually how it went during the last during the last
00:27:37.399
year and the good news is that since then it has been way easier we've been able to um follow more or less the the
00:27:44.720
current the current version of rails still uh what I would say is our lesson
00:27:50.000
and the things that we would do different is what I call First mve first move disadvantage a lot of times at zesk
00:27:57.519
we wanted a new feature for example uh strong parameters and we develop our own version of strong parameters until I
00:28:04.279
think it rails five uh appeared a version that we really wanted to use so we had to remove all our own
00:28:09.880
implementation and go to the to the new one this actually happening right now with sharding we've been using sharding
00:28:16.760
for 15 years with this gem actually it's a public Gem and since real six uh now
00:28:22.360
rails the main branch has a a native system of sharding and we want to move to it and that will be that will be some
00:28:27.559
work that we need to do my advice on this is join the fun if you want to
00:28:34.640
develop a new feature for rails you want to create a a a library ask around maybe someone is already working on this and
00:28:41.279
you can and you can help maybe or maybe nobody thought about that but and you can start but be very public about it no
00:28:48.720
go and annoy people in in in the in the ra re or create an issue talk over
00:28:55.320
communicate okay uh I'm getting to the end I will like to leave you with a a
00:29:00.480
few words so uh this presentation is a continuation of one I did a couple of
00:29:05.640
years ago uh about scaling well mainly about scaling from a performance perspective uh I was very obsessed for a
00:29:12.720
long time with that topic actually I joined zenes because I wanted to learn how to scale a Rel application and
00:29:18.600
actually I as as the MC said I actually writing a book about the topic so it really obsessed me but after talking
00:29:25.559
with a lot of people uh in conference I realize that there is other problems
00:29:31.039
when when trying to scale it's not only about performance the good news with performance is that it's very obvious
00:29:38.000
when something is slow it's obvious or doesn't work uh but when an engineer organization doesn't work is not that
00:29:44.600
obvious when you have a way of working that maybe can another day but
00:29:49.840
eventually won't make it the most fascinating part is that what constitutes a well-run organization is
00:29:55.279
pretty debatable there's different styles of leadership different styles of organization my take is that uh knowing
00:30:03.240
your history can help if you know the history of of Ruby of rails of your own orc or your own company you can you know
00:30:11.880
a lot of stuff that can help you to guide to the Future um I will give you two examples
00:30:18.519
you have you you remember Gandalf like this powerful guy that knows all the Spells and is a is a is a guidance for
00:30:24.720
the for for you know the the hobbits sometimes when you have a a you know a newcomer to the organization you can
00:30:31.080
feel a bit like this that's the good part of knowing the past however there is also a a negative size like in
00:30:37.919
Saruman no imagine like the the past is this is small guy telling you do this do that no you can be trapped in the past
00:30:44.960
like oh this worked 10 years ago let's continue um recently we had this case where uh I wanted to develop a feature a
00:30:51.559
certain way and I had a lot of resistance from a senior leader at like senior technical leader at zesk and
00:30:57.399
eventually told uh hey why why you don't agree I see obviously that you don't want but I don't understand why he told
00:31:03.080
me well two years ago we Tred the same and we failed I asked the reasons and it was something that we were able now to
00:31:09.480
overcome so you know it's you need to know the history but not be trapped by it there is actually an anti pattern
00:31:15.919
called the the Frozen caveman anti pattern that is about that it's like I did things in a certain way and I will
00:31:21.320
do them like this forever so and I'm finishing what's the
00:31:26.399
right attitude when when talking talking about when thinking about history about the past my my my recommendation is take
00:31:33.679
distance from it imagine it's a b like a Storyteller that comes from the past and he's going to explain your stories it
00:31:40.159
can be interesting you should have the attitude of the woman in the picture no okay nice cool maybe you can learn maybe you can
00:31:46.600
use it but don't put your ego in it don't defend it it's not personal hopefully if we continue if we
00:31:53.039
continue observing the past and we learn from it hopefully we we'll have uh for a