Hello, everyone.
Nice to meet you. Nice. Nice to see you.
Nice to have you.
It's awesome to have another episode in
English despite the whole Portuguese that we
have here for the fourth season. Already.
Thousands of episodes for you to listen.
Actually, not thousands, but hundreds of
episodes for you to listen.
I'm Casa Pereta.
I'm Marco Santos.
I'm Rodrigo Bobbin.
And thank you to have you, all of you here.
I'm very pleasure to announce that we have a
very nice guest today to talk about out some
DevOps stuff and some secrets, some best practice, and
we will discover this DevOps word, because so far
we didn't have any episode about DevOps especially.
But today we finally have someone who understand
this because Marcus and Rodrigo doesn't understand shit.
Finally, we can have some specialists about this.
Just before we introduce our episode and our guest, I
want to talk that Devcicom podcast has the support from
Checkmarks and Nova Eight specialized in security of systems and
safe code, all the links and so on from Nova
Eight distributed from Checkmarks in Brazil.
It's on the description of this episode on
our website and also on the YouTube video.
Now I need to talk in Portuguese
because it's focused on the Brazil.
But guys, Contraband Olympia
specializa improves offensive security.
And to remind you that the
Gold Security specialize in application security.
If you want to develop secure
software, talk to the Gold Security.
Okay, guys, done with sponsorship.
We'll be rich one day.
But today, guys, I want to introduce you to
Manuela Manchonne, our first, let's say, Italian guest.
We already have Venezuelan.
We have polish.
We had Americans.
Brazilians, of course. Now.
One from Italy.
Manuela, nice to meet you.
Nice to have you.
Thank you for joining.
Thank you for your time.
Please introduce yourself, talk a bit.
Feel free.
The stage is yours.
Thank you for the introduction. Hello, everyone.
And it's my first podcast, so I'm quite embarrassed.
I'm a very shy person.
Let's see how this goes.
Very much something about myself.
My name is Manuela and I work with Casio
and we have explored certain new topics regarding DevOps
and what we can automate and how we can
do things in an easier way for our teams.
So that's something I'm very passionate about.
And another thing that I want to say about myself is
that I managed a lot of change, and change is different.
So, for example, you can see today we are in February.
My son still wants to have his
little Christmas tree and other decorations there.
This is one topic we are going to
talk about later when we talk about DevOps
culture themes and what happens in real life.
Something else about myself. Okay. I'm in Italy.
I'm in Genova, which is a beautiful city.
Come to visit the city if you ever come to Italy.
It's becoming quite a popular tourist destination and you need
always to have an anchor to keep your sanity.
So this is my sanity.
This is a hardcore engineering project that I'm doing.
It's a sweater. Yeah.
You're a true engineer if you
can learn how to make anything.
And this is another skill
that you need never, actually.
This is a hockey mindset.
You need to be good at anything. Absolutely.
There's no limit to the technologies.
You can use what you need. Exactly. Very good.
Very good introduction, Manuela. Thank you.
For the ones who are just listening to us
on on Spotify or any platform, go to YouTube.
You need to see this awesome weather and understand how
is this shelter behind Manuela with books and so on.
Yeah.
So, okay, guys, let's start with the conversation.
I would start with the first question.
Which is the best, Brazilian food or Italian food?
Manuela. Have you tried brain?
Not knowledgeable enough to no, I'm kidding, guys.
I'm kidding.
But I would say the first thing that we
always not the first thing that we always but
we have been discussing during the podcast was during
the four years that we are here already.
Something about future, especially Rodriguez, has
this word for the purpose.
Future is the most difficult thing to change in
a company, and we have been working through customers
to other few colleagues and so on, and we
feel that the most difficult part is the future.
So, Manuela, what do you think?
What do you think that we can do to change future or
to introduce a new future to a company, to a team?
How do you see this?
This is a real challenge.
We are wrong, and it's easy for you.
How do you see this?
I believe it's difficult for everyone.
Culture is a very powerful
component of everything we do.
It's at our core.
We have our own personal culture.
We have our family culture.
We are typically immersed in the culture of our
country or the countries where we have lived.
And the same is valid also for our teams or companies.
So there might be some teams that are more open
to change, other teams that are more worried about it.
And I think all of these things are very natural.
And whenever we need to introduce something and try to get to
a certain goal or targets that we have, we need to respect
that and to find a way to work with it.
So if someone is having some doubts or some
issues or worries, we cannot just ignore it and
say, hey, no, what we are doing is good.
We want to do it anyway.
No, we have to work with okay, why is it worried?
Why are you worried?
Why do you see concern here with this?
How can we work with it?
How can we give you what you
need to succeed in this change?
It's extremely difficult, and I struggle a lot
with it every time in different ways.
I have learned a few tricks, but yeah,
there are more tricks to learn, I'm sure.
Interesting podrigo, you have some comments around
future because we like this topic.
Yeah, I like very much.
And about the DevOps too.
I see the biggest chalk of the future.
I see in the companies come
from the DevOps all the time.
I see in that company they make the things for the way
and when they come up for the project, how they change.
And DevOps is agent for transformation of the
company because you know exactly how to the
process running and you need to programming the
people for to follow the process.
So I see the DevOps is the most
important for the change at Qturena company.
I think this is true.
Sometimes I like to visualize this as when we are
setting up a production line in a factory where you
can imagine the source code as raw materials.
And then we make this assembly line with lots
of automation and things and people may have the
idea that, okay, before that we were used to
do things by hand and maybe there were some
operations that were more difficult or more chaotic.
And now a machine is doing that.
So what is the value of other people in that context?
Okay, I don't need to click here anymore.
What else can I do?
Can I do fun things?
Can I do things that interest me?
Can I do strategic things
and that empowers an organization?
Very good point.
Mark, did you have some subject around this?
But good or no, because you don't have a future?
I just follow orders.
But we talk a lot of these in the past.
We talk with psychologists
about cuter, about everything.
And Manuel explain very well.
I don't have more to explain.
When you talk about the production, when you get
the manufacturer, for example, and put some process, you
have kind of the DevOps from the factors.
And the bigger change in our culture in
the world come with the industrial revolution.
So they just put some process like the biggest
change in our world, the modern world come from
the VOBs for the factory industry revolution.
Yes, in a way, yes.
Interesting point, very philosophical today.
Thank you for a collaboration online.
I would add to the discussion something like this
about specifically the future, because we already agreed that
it's hard to change because of many factors.
Like Manuel said, okay, we have our country family stuff
that we are already attached to it and the problem
we face here we are free from security, Manuela.
So imagine we are trying to get
into company's futures and usually those company
futures do not have security at all.
Of course, where we work we already have something,
but these companies don't have security at all.
So imagine we need to step in with new
processes, new tools, new practices, et cetera, et cetera.
All these new in stuff in the process.
It kind of bothers them, especially developers,
especially these companies, who has the mentality
of we need to deliver as fast
as we can because business cannot stop.
We need to sell more, sell more, sell more.
And they struggle with these new things, even
if there's new things and not from security.
We are talking from security because
it's how we come there.
But usually even for new DevOps processes.
I was working with Rodriguez in a tourism company,
biggest in Latin America actually and they were struggled
to have DevOps processes because they were waterfall style
and then they moved it to Agile and all
this changing was kind of very painful.
And what do you feel that it's like smoothly
or easy or technique tips that we can do
to start introducing this new future, this new stuff?
For example, this reminds me of when
I started as a configuration manager.
There was no configuration manager, people didn't really know what
it was, I didn't even know what it was.
It was the first time I had that kind of role
and I started to look at how I could help people,
what was difficult for them and what part of my role
could help them and I focused more and more on that.
So you may find out that people are
struggling with something and they have a higher
motivation to do something in that area.
So that is something where you can start a trust relationship,
say oh, you have this problem, you are aware of this
problem, you want to change, you have motivation, I'm here to
help you, I can help you in this way and this
is the benefit that you will have.
Interesting, maybe with maybe small things that bring
value to them and they realize okay, this
is a collaboration that is giving me something.
Good point.
Easy, easy, very easy.
It's not easy.
You can't even talk with these people because they will
say no, no, I don't have time for this.
Yes, exactly, they would have time once they trust you.
You showed the great gain when we
put some process automation process but the
people don't understand you about this.
And then I don't have time to make this
but I will give time for you when automated
for you in this process before the DevOps.
All the things painful for this when you compile
code, when you build you need to send for
server now you don't think about this.
You don't have to think you have the tools for duties.
You just think about the product and your code.
But don't think about this, just think about the now.
Now I will lost 1 minute for building.
Interesting point.
Also I would ask another question or put
the discussion in another direction kind of okay,
I heard us actually once that DevOps is
not positioned, it's kind of a mindset.
Do you agree with this?
Yes, I think so.
As a configuration Manager, for me,
DevOps is like a style, okay?
We do configuration managers.
We are a control freak.
We want to control and track everything.
But DevOps is a style that makes things
very lightweight with lots of tools to do
the tracking, to do the complex stuff.
And we have all the data.
We don't need to worry about writing a
long document that describes the baseline with versions
and gets approved, reviewed, blah, blah, blah.
No, it's there, click, done.
And that makes me feel very good because
I don't have to sweat the small stuff
and I can focus on strategy instead.
So I like to see as a style, maybe in a
few years there will be yet another style which is different,
even faster, even more with better user experience, more like, hey,
this is a creative service and we're all experiencing it in
a very nice way, like going to a shop.
I don't know what's going to happen in the future.
Those concepts that are at the core
of what I do are configuration management.
Those are very logical, very deeply rooted
in the nature of what we do.
Then the style could be called DevOps, could
be called shop software, blah, blah, blah.
Anything interesting?
Another point is like we need to rely because as
you mentioned, like wood is a style, but we need
to rely a lot on tools, on tooling, definitely.
Which means we are not pushing buttons all day.
Instead, as you mentioned, like we are thinking a
strategy of creating an automation or creating a process
or automating a process itself to make this happen
in a more agile, efficient way.
So around tooling, do you rely on tooling?
Do you create your own scripts or tools?
I would say, how is it for you?
How is your daily stuff? Okay?
Anything goes.
I rely a lot on tools.
We have those basic tools in place for the
organization to work and track activities and track everything.
But on top of that, there are extensions, there
are discoveries, there are custom scripts and tools, especially
when working with pipelines that build the software.
It's very easy and very natural to add your
own things, add your own PowerShell, script here and
there, a few rest APIs, blah, blah, blah.
Customize the behavior.
I do all kinds of things.
I showed you earlier, my other
project, I don't spare any technology.
Anything that helps me get where I
want to go, I will use it.
No, always in an ethical correct and safe way.
But any possible thing that we can use
and it's good to use, yes, that's valid.
Any ideas that can be developed are good, interesting,
and it's one of the principles of security, which
I forgot the number, but it's exactly about not
relying on technology to have security.
Like, I heard already some teams discussing like
I cannot encrypt this kind of data because
we don't have encryption on our framework.
So what the hell?
You are not encrypting because you
don't have on their framework.
So find another framework, find a library or something.
But you need encryption.
That's the point.
And this is interesting point, Marcos.
I remember once we were working with some
partner, I would say, and they were kind
of struggling that they do not have any
kind of programmers, any kind of automated guys.
They cannot run anything.
So they were looking for a tool
that we are selling this tool back.
That they were looking for a tool like, okay,
I just want to integrate this tool and push
a button and don't do anything more.
But they had all the pipelines we need to integrate,
we need to do the scanning strategy and so on.
Remember this case? Yes.
Remember this case?
In the past, I don't say the name, but in the
past, the people asking me about I don't have anything inside
my company, but I need to scan, I need to compile,
I need to put security to put everything inside my company,
but I have a low budget and I don't have tools.
Find a tool for me and the implants for
inside my company now, easy, no, very easy.
And the most problem is people think cybersecurity
or tooling is afraid or don't have complexity.
And people think, oh, no, complexity. Easy.
It's only one more two and you need two days for this.
It's not good. Exactly.
Terrible.
And Manuela, you mentioned the interesting point
now that you have kind of coding
skills, because you mentioned PowerShells and scripting.
There scripting here.
Do you think this is kind of mandatory for this
style, as you described as DevOps or configuration manager?
Or do you believe that?
No, it's not mandatory for this area.
You can succeed without any scripting.
Let's say it's mandatory for me.
Without it, I would feel very limited.
If you can just use what has already been
done by others, sometimes you also lose the ability
to imagine what is feasible, what can be done.
And that's very empowering.
That can give you that extra strength.
That good idea, that inspiration to do things better.
If you don't know how to make
things, you can just buy them, basically. Yeah.
Interesting.
So, Hodrigu, you are back already.
I have a question here with a lot of crying here.
No, that's fine.
I have a question for you.
Do you believe, like Manuela just mentioned,
that it's mandatory for her to have
scripting skills, let's say not developing skills,
but scripting skills, which is different.
Do you believe the same for application security?
Like, we need to do code reviews daily, we
need to tune some Saskans for the customers.
Do you think it's coding?
Excuse me, I understand the code. It's mandatory.
Yeah, you need to know script.
For example, I make a troubleshoot for hazoot
of the desktop scan and the tool.
I can see what happened because a lot of
time for and I used some scripts in the
shell scripts to make for finding the Kind, I
lost maybe 30 minutes for doing this using script.
So I lost a lot of hours in the
tools to try to find the same thing.
So the shell script is a powerful tool.
When you see the Black Spring,
maybe you have some hardy things.
So for automating all the things you use scripts or,
I don't know, to gather some data or crawling.
It's mandatory.
No scripts for this.
Maybe all the areas in it.
Yes, I would argue that, especially for application
security, as we're mentioning, I see a lot
of customers, a lot of developers, I mean,
not developers especially, but a lot of general
people involved in vulnerabilities.
They are marking some outputs from the tools, from
SaaS Solutions, from Das Solutions as a false positive.
And in two minutes discussion with the same
people around this vulnerability, I was proving them
that it was not false positive.
It was a real vulnerability.
Which makes me scary because I was a developer
for 15 years in C sharp, Java, Python, whatever.
And when I see code and I see a
vulnerability, I know if it's vulnerable or not.
I know it's false positive or not.
But I don't believe that all the developers without
the secured skills and all the security guys without
the developing skills has the same approach.
When you find a vulnerability, it's the same.
You go to a doctor and one doctor say,
oh, unfortunately you have a concern and you go
to other ten doctors and no, you don't have
nothing, but you're going to stay with that one
in mind because that one is more dangerous.
Then you're going to find another
option, another opinion, another opinion. Then what?
Who are you going to believe?
And I think we have the same problem
when we talk about application security, because a
lot of security guys don't know code and
a lot of developers don't know security.
So they need to trust on the tools,
and the tools produce also false positives.
It's normal, it's mathematically proven that it's
impossible to not have any false positive
kind of scanning tools and so on. But Mark is gone.
You need to make some comments.
That's okay.
I have a comment because nowadays I'm working more
hard with the EAC if the infrastructure is a
code and I see so many vulnerabilities and the
people ignored this vulnerability because so many scans when
I try to find, okay, let's go see.
And the guys I see the secrets inside the code
password, don't put the version of, for example, I know
how it is and no security is the group.
I find so many vulnerabilities.
Oh my God, you think is correct.
Your secret is inside here.
Manuela, I have a question for you.
Do you have secrets on your PowerShell script?
Yeah, hopefully not yet.
I have secrets in places that manage secrets.
Awesome, perfect. Awesome.
I have one item in my backlog to
run a scan to find out if somebody,
without realizing, has stored secret somewhere.
Very good.
But I have cybersecurity people in my organization, and
I talk with them and I work with them.
That's the point.
When you talk about security itself, because we have
application security, we're going to take care of the
application itself, and we have dev saccops absolutely.
That we're going to look for the
secrets on the codes, or who watches
the watcher, who can give permissions, etc.
We are discussing projects similar with this time ago.
And that's the point.
We understand the need of this and we grow.
We give you one step forward and one step forward.
And this is coming back to the future.
As we are discussing, we are kind of open.
You are open to understand what's
the need from the security perspective.
I am open to understand what is the need
to run with the scripts and so on.
And we match these two ideas, let's say, to
have a better solution for me as DevOps.
When I find a problem, I like to have
someone whom I can trust to say, okay, I
have this thing, I don't know what to manage,
because this is not my idea of expertise. Help me.
When there is this contact, then I can come to you.
If I find a vulnerability, I can come to you.
I can talk.
Okay, I found this.
Now what?
Before, I can believe that tendency to say, no, this
is not a problem, because I don't know what to
do with it if it's a problem now. Very good.
So this advice all the developers
listening to us should take.
Oh, I found Aunt Abett.
What I have to do with this?
Do not suppress the warnings, do not
ignore the code and so on.
Because as I always say, when we need to defend
our company, we need to know about all our problems.
When the hacker needs to attack, he
just need to know about one problem.
They just need one breach, one door, only one.
And we need to know all of them to defend.
So it's much more harder for us.
And usually we work with the Avengers.
When something screw up, they call the Avengers.
The security, come here, we have a problem.
Call the Avengers.
But it's already done, guys, sorry, sometimes
you don't have it to do.
Okay, so coming back to our main topic,
let's say, manuela, what do you think?
What do you believe, actually, that are the challenge not
for you, but for the arena challenge in this DevOps
device, tech, ops, security stuff, even best practices.
What do you feel that is the most hard part for you?
Okay, the worst part for me is when we have
many tools and they don't really talk to each other.
Like we do scanning for open source, and
we have the results in one place.
We do static code analysis, and we have
results in another place, and our results of
the pipelines are deliverables in another place and
they're not maybe related to each other.
That's a kind of spaghetti DevOps where
you don't know anything and it's crazy.
You know, you have lots of data, you don't really know
what to do with it, how to relate one the result
of a tool with the result of another, and how to
really process and have a meaningful process around it.
Interesting.
Do you also believe that lack
of documentation is a problem? Also?
Some companies I don't know.
It's risk for companies, especially when
people keep changing, that for sure.
But I would see it as a general risk,
not specific to DevOps or devs ups that's risk
for everything around what that company does.
You can arrange business rules or whatever?
Yes, if only you rely on one person, this person dies.
That person decides to go on vacation or fire or die.
Okay, maybe that's not a conscious decision.
People can find a better job at our
maybe rival company in a day and disappear
because they really want that person.
These things can happen, and we'd better be prepared.
Okay.
Someone even mentioned something.
Hodrigo or Martin also no, I think about this question.
The most challenge to implement
something is just the future.
And the people don't open for the my son
who doesn't want to remove the Christmas tree.
How do you convince him?
Okay, in this case, he's a four year old,
so he would do it when he's ready.
Maybe we can do other things
because we're dealing with adults. Exactly. Exactly.
So, for example, few days ago, I had a
discussion with a team around hardening, hardening stuff.
And this team was saying, no, we are using
containers, we don't need to care about hardening.
And I was, okay, but you use a container, you
have a base image, you open ports to this application.
How do your file system configurated?
You can access anything on the file system.
You have read permissions, write permissions.
So you have some raw hardening to take care of.
But that was the point.
They didn't know, and they are just
avoiding to do the requirements there.
And I was discussing like, okay, guys, you need to
take care of this, because they were open to listen.
Okay, we didn't see this perspective.
Okay, so we need to handle we know how to
handle we were going to implement this, but it was
just five minutes talk and everybody understands what I most
face during the day or daily basis, even with partners
and customers and so on is this problem.
Some of them don't want to talk, as
Manuel was mentioned, like, I don't have time
you can even talk to to these people.
And this is the problem.
How to reach this guy, how to and
one interesting case company that I work, we
had the kind of a workshop monthly.
And this workshop was around the Vulnerabilities
best practice and security and so on.
And it was not working, but stopped working
when I was presenting incidents on the workshop.
Random incidents.
But in the end of the workshop I was
telling, look guys, for this specific thing this incident
happened in your system last week we had a
breach and some something this imaginary fear to the
reality of them like oh, this is happening, it
already happened and we had an impact.
It was making them move the managers and so on.
They were going to the chairs and okay, now
we need to do a course, we need to
start scanning, we need to start this and that.
But you know, this reaction instead of being proactive
on this, protecting it's what I still struggle and
I'm kind of how do we make it better?
How can we do it better?
Somehow it sounds to me like there
is one component of fear that arouses
interest but it's also about storytelling.
When you tell a story, whether it's bad or
good, we humans are good at processing it.
If you just present data less good at it.
If you have this kind of story, this thing happened.
Okay, there's interest and the same goes sometimes when
I do meetings or what I'm engaging with communities.
People want to say that they like success stories
whenever we ask, okay, what kind of topics would
you like to include in our next meeting?
Success stories.
They want to know what has happened,
what people have done, good or bad.
Okay, sometimes, but mostly they like to hear good
news and I think that this could be this
could help us with communication and with having more
interests or openness to listen to us.
As a good Brazilian, I would say that Brazilians like this
popopolis a lot of drag them out and so on.
So maybe the bad parts would be good.
Once upon a time there was a database
with a credit card information and was leaked.
Good it was yours.
Interesting about to start telling
you what do you think?
Marks very strangely but because of this history I remember one
of their history a long time ago my boss no have
a good idea andy I asked my help oh my gosh.
I need to turn off the logs
because we have a lost space.
We don't have more space inside the servers and you need
to turn off the logs because no space, same space.
Okay, I turn off the logs, but advice okay,
but if I have some problems during this prior
I don't have any chance to find the problem.
Okay, that's okay.
Sometime a little time after I turn
off the logs, we have a leak.
So many information of one of these employees was
leakaged and my boss okay, mark find the person
was leaked okay turn on the logs because I
don't have logs to find the person was leaked.
This.
Story is not new for us.
This is true, actually, and it's funny.
Turn off the loud to save some space.
The best one terrible is the same one.
The opposite would be like something that I
heard a lot is give admin access because
you need to do something admin access.
Sometimes you don't need full admin
access, you just need specific permission.
But admin is easier.
In this case, for example, to save space, turn
off the log instead of doing kind of a
rotation or deleting all the data and so on.
But turn off the logs anyway.
The best idea when I see my life.
Manuel, another point that I would
like to discuss is around education.
What do you think?
For listeners?
Either for security people, developers, what it's good for
them to learn about what you do, for example,
on DevOps or config management and so on.
What it's good for them to learn if they
want to be more collaborative for you, or either
for who wants to work as you do what
they need to learn, what they need to study.
What do you learn?
Okay, regarding configuration management, it's quite
difficult to learn about it. I think.
There are only a couple of
university courses specifically on it.
One is in Sweden and one could
be in Brazil, maybe, I'm not sure.
There are, of course, books.
There are people who write about it.
There are some communities, but
that's quite difficult to digest.
I like to read a lot DevOps blogs.
There's a lot about communicating, what they do,
how they do it, what are the results.
That's very practical, very understandable.
So I would look for resources for blogs
like DevOps something or dev second Ops something.
And I would search for the kind of
tools and how they can be integrated.
Regarding learning, okay, it depends a lot on
what tools you use, but some common technologies,
some common things that you may want to
learn are YAML for managing pipelines?
This is valid for Asia DevOps, for GitHub.
I don't know where else it is used, but I use that
a lot on a daily basis and some script, whatever you like.
Nowadays, I think most systems allow us to
write scripts and use code from any kind
of scripting language, executable, ZLS, whatever.
So what is it comfortable to you keep using it?
I have studied Java at university.
I use a lot of C sharp when I need to use PowerShell.
I'm curious about learning more web oriented stuff
because I see many things happening in pipelines
or extensions being developed like that.
Be curious about something to this list.
Now maybe manuel talk about the tools, but the one
thing I think now is you need to be curious.
You need to want to learn more and more all the
days now that the new stuff come all the days.
So you will be to manage some new tool or you
need to learn you need to be interesting for this technology.
Yeah, that's the point.
Because I don't want to say my age, but from
the past we were like I am the back end
developer, don't bother me with CSS and JavaScript.
I am the C sharp guy, fuck you.
It starts moving to now you need to
start dealing with the interface, which I hate.
Now you need to document, then you need to know
about database and then now you have full stack whatever.
Now you need to do DevOps because you
need to from the code to production.
But don't forget about security and you need
to do testing and you need to make
coffee and clean your desk already stressed.
You need to know a lot of things and
maybe this is also hard to keep important things.
So for example, security is one of them.
Quality in general, I would say it's one of them.
Because if you are focused on the coding, performance
and best practice of the code itself, today and
tomorrow you're going to think about security.
And tomorrow you understand better integration
on your pipeline and testing.
Live for the Q and A
team and about configuration in production.
You don't care.
And maybe all these things that you need, I
mean market is forcing us to know from one
perspective it's good, I don't complain about it.
But from the other one we may let
other things be less important for us.
So for example, I would say Manuela, she has her focus.
My focus is this part of the job.
I will not care about best coding practices.
For example, I need my scripted to run, I
need to get data from here and put there. That's all.
You understand the point.
Maybe I should not be worried about modeling
these creeds or creating a real program to
being reused and just some examples.
But there is some kind of
point of contact between these roles.
For example, I don't care about the details of
coding guidelines, but I am aware of it.
And if someone in my team needs to work with them,
I can point them to a way to embed the pull
request checklist automatically in their repo in order to use this.
So there is a kind of process or flow around
these things and we need maybe at least a minimum
amount of understanding of the other topics, how they are
relevant and how they are tied together.
I'm supporting multiple teams and there's a lot of
work to do, so I cannot do it all.
And that's something very common
that happens to everyone.
So there are some people in
my teams that are more interested.
There's one guy who's very curious about Yamaha
pipelines and the moment he showed interest, I
was very happy to talk with him.
He's a tester.
I was very happy to talk with him to share
some tips and tricks and now he's doing quite advanced
stuff on his own, but I have less workload. He is happy.
He's getting what he wants.
And he has also learned something fun.
That something that he enjoys doing, which
is not 100% his core business.
But we have this collaboration.
It's good.
Manila is talking.
Remember when Daniella talked with us and Danielle is
a VP of Engineering and study a lot.
She needs to code in nowadays.
And it's good.
Very good.
This episode with Daniella was actually was
one more teacher because she's from Portugal.
We are moochi culture.
And it was about half specifically because she
is the VP of Engineer from Checkmark.
She knows everything about gold scanning and
so on and all this works.