Hello and welcome to episode 3 of season 2 of the Google SRE podcast or as we affectionately refer to it, the podcast.
Here with me again as co-host is Pam.
Hello.
And today we're going to be hearing from a couple of SREs here at Google who are a little further along into their careers than the folks we already heard from.
And we're gonna go ahead and let them introduce themselves.
Hi, my name is Theo Klein and I've been a site reliability engineer here at Google for just over three years.
Currently I work on the reliability efforts around the infrastructure that powers the ingestion, curation and storage of all of the data that powers Google Maps.
And this is essentially my first SRE job, my first real job out of college and it's been super awesome.
Hi, my name is Shannon and I work on the G-Linux team.
Google has our own internal Linux distribution based on Debian testing.
So I work on the team that does development and maintains that operating system.
I've been at Google for just over seven years and I have been in my role as an SRE for two years, having worked the previous five years in our internal support team.
Then why don't we start with you Shannon, around that.
What was your path into SRE coming from those other support teams and do you want to get into that story a bit?
Yeah, I'd love to.
So I got my start working at Google through what we call TechSup, which is providing internal support to Googlers.
I was lucky enough to get an internship in our Boston office in my junior year of university.
Then I was able to convert into a full-time postgraduate program called the IT residency program.
So I worked in our New York office for 26 months.
And then I applied for a permanent position in TechSup as what we call a Corporate Operations Engineer in London.
And I worked in that role for five years.
Linux has been a lifelong passion of mine.
So when I was working in TechSup for those five years, I was really focused on Linux support and providing the best experience possible for our Linux users internally.
So after the five years, there was an open head count on my current team.
So I applied for it and was lucky enough to get the job.
I've loved it ever since.
That's awesome.
Theo, do you want to share your path into Google and SRE?
Yeah, sure.
I came into SRE pretty much straight out of college.
At university, I was studying cognitive science and computer science.
I really had no experience in computer science prior to university.
In university, I didn't really understand what the industry was like.
And I stumbled into an internship at Microsoft where I was doing software engineering, like pure software stuff.
I was working full stack on Azure.
And I knew that I wanted to be in New York City after university.
And unfortunately, Microsoft didn't have any offices, any engineering offices at the time in this area.
So I applied to Google and at the time, the only position that was open was in site reliability engineering.
And I said, what is site reliability engineering?
I have never heard about this before.
What is this?
And then initially, I was really skeptical.
I thought, OK, I'm going to be doing a lot of DevOps stuff.
I'm not necessarily interested in DevOps.
What I like working on is algorithms and improving code.
So despite that skepticism, I knew that I really wanted to be in New York.
So I applied and I ended up getting the job.
And the thing that really held me into this position initially was the fact that if I didn't like it,
I had the opportunity to transfer from the position called SRE SWE to full SWE.
So SWE means software engineering.
So I told myself, I'm going to give it six months and see if I like it.
And if I really don't like being a site reliability engineer,
then I'm going to change teams internally after six months of being here at Google.
And I'll just give it a shot.
And so I joined Google.
And for a variety of factors that I'll get into later,
I actually fell in love with site reliability engineering.
And so I've stayed in SRE for the past three years.
And I've actually stayed on the same team for the past three years.
It's really awesome to hear your perspective, Theo,
and your almost hesitation at getting started as an SRE.
I can really relate to that myself.
When I first started at Google,
I had this very specific mental image of what an SRE was.
And when I looked at my own mental model of myself,
I didn't fit into that.
And so when other people started suggesting, hey,
have you thought of this as a career,
I was very hesitant too,
especially because everything that I thought of an SRE as being
was coding, coding, coding.
And I was really lucky enough to do a rotation with an SRE team.
And I had a lot of really great encouragement
from other amazing engineers that I worked with
to pursue this job.
And the reality is that SREs come from all walks of life
with different backgrounds.
And it's that diversity that makes our team stronger.
For instance, having been in user support,
I've always had this mindset focusing on users,
how they'll use our product.
And that comes into effect when you think about
how rollouts are going to affect people,
how communications around that have to go.
And we have a strong mix of both SREs,
like you, but we also have site reliability engineers
on what we call the systems engineers ladder.
I'm not as good of a coder,
but I have a huge background
and lots of interest in systems engineering.
So I'm a Linux person.
And having that mix of SREs
and the Sitchens folks on every single team
has really made us as SREs
and our team stronger
because you do have that diversity of background,
that diversity of interest.
And we work better when we're all a little bit different.
Our skills complement each other, truly.
Definitely. That is the best way to put it.
And I think one of the standout things with going into an SRE role
is you do kind of need a little bit of both, right?
You still end up taking the coding interview
and if you weren't coming right out of college,
you would take possibly a system design interview.
So you do need to know a little bit of both coding and systems.
I feel like as you grow in your SRE career,
you do level up in each category
so that you can not only write the code
or you can also review the code
and you can not only design the system
and also review the system design.
Thank you for sharing both of your stories
and your hesitations with us.
That actually does make me think of something
that I think a pretty powerful and important phenomenon in SRE
is not only do we kind of need to have these broad-based knowledge
between software engineering and systems engineering
and everyone kind of has a little different mix of that,
but then within a team, people develop a niche
that they fit into
because we can't actually know everything
even about the systems we support.
So I'd be curious to hear from each of you about
your journeys like finding your own niche
once you became an SRE
and how a little bit of your journey as SREs has developed?
Yeah, that's a really great question
and I totally agree with you that
the individual members on my team
have specific expertise in different areas
and with that said,
if you have an interest in an area that you are not an expert in,
I think that, at least in my team,
we're very encouraging to allow people to explore.
But in particular with my journey
and finding my expertise,
I had always signaled an interest in doing coding projects
and so from the very first project that I worked on,
I was essentially working embedded in a specific developer team
to improve the reliability of their system
through software engineering projects.
So my very first project was working on a very important
core piece of Google Maps infrastructure
and it was running on some very legacy binary
dating back to say like 2008
and no one had touched it.
The only thing that was updating in this binary
was the data that was being served by this binary
and times change, systems change
and the requirements change for the production environment
and none of those changes had been implemented in this old binary
and so my goal, my responsibility for this first project
was go into this extremely important piece of system
and modernize it, bring it up to date
with the best practices of SRE today.
And so can you imagine as like a new grad coming out of college
and then being handed a project that says
take this central piece of software,
if it breaks, you know, you break Google, right?
But if it breaks, you break Google,
but you are now responsible for bringing it up to times
and that was so crazy.
That first day after I left work for that day,
I was so scared.
But at the same time, I was also really excited
because I knew that I was going to be working on a really important project
and so it took me a few months and I launched it.
The launch window was several months long
for different parts of Google and it was a huge success.
And so that sort of told me that I needed to find the scariest problems
in the problem space that were on call for
and find ways to solve that with engineering.
So for the few projects after that,
I kept on doing similar types of projects
where we take old systems and we want to modernize it
or we want to migrate back ends.
And so I'm not necessarily building new features, right?
The API layer of the system remains the same,
but the internals are changed such that the reliability is increased.
Now over the past year and a half,
I've been working on a slightly different project,
a project that we call Zero Outages.
And the goal of this program is to essentially eliminate all serving outages
from the services that we're on call for.
The way that we do this is that we're actually automatically analyzing
all of the dependencies in the system
and ensuring that the dependencies that are in our system
are meant to be there.
And so we have an auditing tool that will flag risky dependencies
and then we do engineering projects to remove those risky dependencies.
So in that way, it's sort of a two-pronged approach.
We've got the auditing tool that will generate alerts.
And so I put on my program manager hat
to manage all of the alerts that are generated.
And then I do engineering projects to mitigate
or resolve those risky dependencies.
Shannon, what has been your niche at Google and SRE?
Obviously having a user support background,
that sort of mindset, user support, UI, UX,
is a niche of mine.
But I didn't find my true SRE hat niche until I got my Nugler project.
And originally, the bug I was assigned was a little tiny compact bug.
I thought it was a good bug to start with
because I had an idea of how to fix it.
But then when we started diving deeper,
it was a seven-year dependency full of spiders
that nobody had wanted to touch.
And so it became this huge project, this huge Nugler project.
And it was really important to get it right
because upgrading to this dependency
was going to mean a fundamental change
in how people interacted and used their Linux machines
at a critical time where people were sometimes in the office,
sometimes working from home.
And so they really needed to make sure
that they had a consistent experience with their machine.
And not doing this project was no longer an option
because the upstream community had moved on
and we were deviating so far away from what upstream was going to do
that this project had to be done.
And we had some very critical dependencies
that we couldn't upgrade.
So we had to imagine a solution around it.
And it was so interesting to really kind of dive deep
into critical, low-level Linux fundamentals
like Dbuzz to really understand what they were doing
and how they were interacting with every other part of the system.
And so I designed a solution for this upgrade
and I coded it and we tested it
and we went to go send out the email telling everybody
that this is the new hot shiny thing.
We got a lot of negative feedback
and we didn't actually end up going with this solution.
We ended up having to take it back to the drawing board
and re-engineer something brand new.
And the cool thing about that is it became an even deeper niche
because now we were thinking about a program one way
and now we have to explore even deeper
to reimagine this whole solution.
It was more complicated the second time around
but we did end up releasing something
that met all of our users' needs that was supportable,
that got us past that dependency
that we had been somewhat avoiding for years.
Now that that dependency is removed
and we have this thing I designed.
I am now the subject matter expert of this design
and the cool thing is that we have a bunch of different projects
that kind of touch those relationships that I developed
while working on my nuclear project.
So now I have this niche and these connections
and the subject matter expertise
that what I originally thought would be this one tiny little project
is now something that touches my day to day work
and multiple projects going forward.
But the whole experience had been just really great.
My team supported me the entire way
through the initial rollout to the secondary rollout
to supporting it.
What I really like about this is that it really demonstrates
the variety of areas that SRE has expertise in.
You're working in a quite a low level
in the tech stack, so to speak.
You're working very deep on the internals of Linux
and how Linux operates
and how all of us at Google get to use Linux.
Whereas I work at the very top of this stack
where I'm thinking only about the business logic
and more abstractly how the different components
of business logic interact with each other.
At the same time, we need SREs throughout this whole stack.
We need SREs that focus on the internals of Linux
but we also need SREs to think about the broader view
of how our systems operate
or how the business operates through the code.
Definitely, because the thing about SRE
is that those principles of site reliability engineering
work just as much on low level Linux internals
as they do on high level business infrastructure
as they do in the back ends that keep Gmail running.
When you design something,
you want to design something that is fundamentally reliable.
It works.
That you're developing something that users need
and users can use and that you know will work
because you don't want to develop something
that whether it's high end business logic
or low level Linux internals,
that is going to break and you're not sure why.
So those principles of site reliability engineering
are fundamental, wonderful engineering principles
that do a lot of good things for teams across Google.
That's pretty awesome.
It sounds like both of you have had really impactful projects
right from the start in your SRE career.
You've mentioned getting team support for these projects.
What is your support network like as you got started
in your SRE career?
So I'm super lucky that I started in the IT residency program
because there's such a strong alumni network
of people who used to be in that program
in all different roles like Google.
And it's really amazing to feel comfortable
reaching out to these people
and they know exactly what you're going through
because they've been there themselves.
And so that's a really strong support network
that I was really lucky to have
and they were able to give you advice
about what it was like to be an SRE
and that sort of encouragement.
But also my team is just an amazing support network.
Going back to that first failed rollout,
my team provided so much support
in that they made it clear that an engineer is never in a silo
and project is not just one person.
So other people contribute to code when we as a team,
somebody reviewed the code,
multiple people coded for it
and as a team decided what direction that we wanted to take
and we agreed on it.
So the amazing thing about being on a team
and being an SRE is postmortem, blameless culture
is that your team is always there to support you
and whether things go bad or things go good,
you fail and you succeed as a team.
Yeah, and to add on to that,
the postmortem culture,
especially in SRE, I think is extremely strong
and it has allowed me as an individual
to put my team to try out risky projects
and risky actions without the fear
that we will suffer the blunt of the repercussions
if the risks don't pan out
in the way that we would like them to.
And so something that I always think about
when I go on-call, for example,
is something that my manager repeats often
and it's that my manager will always have my back
for every decision that I make when I'm on-call.
Even if, as a constant against my action,
the system operates even worse
than at the beginning of the incident.
And we've had moments where I have issued a command
or a colleague has issued a command
that has globally taken down a service.
And the way that we interpret that
is not that this engineer has made a mistake
and that they should be reprimanded,
rather, the way that we interpret that
is that the system was designed in such a way
that allows this vulnerable action to be made
by an engineer, by a human.
And therefore, the system is at fault.
And we should change the system to be more safe
and prevent those actions from being made in the first place.
And that nuance, I think, is so important
because it allows us to make faster decisions
and to worry less about the potential negative effects
that may happen as a result of those.
And I guess another point here is that
by changing the system as opposed to changing the person,
we can ensure that when that person leaves the company
and a new person joins,
that same mistake won't happen again.
So these rules are encoded in the system
as opposed to the person in their mental model
of how on-call operates.
One thing that I think is really cool as well
is that this post-mortem culture has sort of bled
into my personal life and my social life.
So I have a partner and at the beginning of our relationship,
it was very much me versus them.
I can't believe you didn't do X or I would receive,
I can't believe you didn't do the dishes.
You have to think about this and that.
And with this blameless post-mortem culture,
we're reframing the disagreements
or perhaps the negative things that happen
as a factor of how the system got us into that situation.
And so now it's much more about me and them against the system.
And that has become so beneficial for my relationships
and for my social network.
I was giving a small informal talk to some folks
when I was traveling.
These were high school students.
And I was giving a talk on this blameless post-mortem culture.
And I was stepping through how we do this at Google
and I was giving very technical examples.
And at the end of the talk,
a teacher came up to me and said,
oh my gosh, I wish you had been here six months ago.
And I say, what do you mean?
And this teacher elaborated
that they had gone on this international trip to Germany.
They're based out of Argentina.
And in this trip,
there were many things that went wrong.
There were certain incidents, so to speak.
And the students that experienced these incidents
decided to, or they were very frustrated
because there was something about maybe a bus not working properly.
Maybe there weren't enough seats or perhaps they were late.
And the students were understandably frustrated,
but they didn't really know how to express it.
And so there was a lot of blaming going about.
Some teachers were blamed,
some administrators were also blamed for whatever happened.
And they realized that they could have used this blameless post-mortem culture
to analyze the system in a way that would have been much more constructive.
And so after I spoke to them about this,
they actually re-analyzed all the failures that had happened on this trip.
And they were able to make some changes,
which I thought was so cool.
So this culture of blaming the system as opposed to blaming the people
I think has ramifications beyond just SRE and computer science.
But it's a very social thing that I think allows us to make more efficient progress.
I 100% agree with you.
Blame serves no productive purpose.
It doesn't serve that in your personal life
and it doesn't serve it in your professional life either.
Because if you think about it,
if you have people who are afraid of the repercussions of a mistake that they made,
they're not going to want to talk about it,
they're not going to want to admit it,
and then we lose the opportunity to make things better.
If you give people the opportunity to say,
I did this thing, it did not work,
we can now talk about why did it not work,
how can we make the system better.
Critically, part of the blaming the system, not the person,
is also not blaming the person who designed the system.
Because that is a very key part of that too.
It's not that all the person who designed the system is bad
and their design was flawed,
it was how can we make it better.
So that is super important to think about it.
And that blameless post-mortem culture
is something that we teach from day one
in SRE orientation at Google.
Because it is that important to make sure
that we learn from everything that happens here.
Additionally, when an outage happens or something happens,
a team can always request a post-mortem
of an outage or a problem or a bug or whatever.
And the cool thing about being in SRE at Google
is that obviously you work with other partners,
developers, SREs.
And so when something happens,
another team or person can always request a post-mortem.
And just like they should not be afraid of asking for one,
nobody should ever feel bad about having to write one.
It's not a punishment or a bad thing to have somebody say to you,
can you write a post-mortem about what happened here?
That's never a bad thing.
It's not a criticism about your project or your code
or your handling of a situation.
The attitude at Google is to be open and honest
and have these difficult conversations.
To add on to that, I would be even stronger
in my opinions about post-mortems in particular.
I love writing post-mortems,
and I love talking about post-mortems.
Surtout parce que je pense que c'est cool
de voir comment nos systèmes se brûlent.
Et de juste se rassembler en amazement et dire,
oh mon Dieu, c'est les procès.
C'est tellement compliqué.
On a l'air de la Terre.
Et je pense que c'est super excitant et fun.
Je pense que cette description vous montre
que vous pouvez réfriger ces incidents
dans un lit positif
comme une opportunité pour apprendre
en tant que l'expérience d'un scère
comme vous l'avez déjà dit, Shannon.
Un de mes mentors de la SRE
qui est Tanya Riley,
c'est incroyable.
Une des choses qu'elle always dit
aux nouvelles SREs,
c'est que quand il y a un outage
et quelque chose se passe,
la meilleure façon de penser à ça est de vous remercier.
Merci pour ce bug.
Merci pour ce fond de la mobilité.
C'est pas... Oh, man,
maintenant je dois fixer la chose.
Merci pour nous montrer
ce qui peut être meilleur.
Elle serait toujours d'aller
être heureuse de votre outage,
de faire des lessons à l'étudier.
C'est un moyen incroyable
et un moyen superbe
d'approcher un outage.
C'est super pour faire un post-warrner
de la SRE.
Nous faisons une avec toutes les plateformes.
Et c'est tellement intéressant
de voir comment tous les différents équipes
qu'est-ce qui s'arrête
parce qu'il y a des fois
que d'autres équipes
présenteront un post-warrner
à un film de post-warrner.
C'est un moyen incroyable.
Maintenant que vous êtes prêts,
nous pouvons nous fixer.
C'est une des raisons
qu'on a besoin des post-warrner
parce que beaucoup de temps,
le travail d'engineering que nous implementons
vient comme résultat de ces post-warrner
parce qu'ils identifient
les risques systémiques
dans nos systèmes.
C'est partie de notre blanche.
C'est un sujet très intéressant
parce que les post-warrner
sont un lait
de ce qui est si grand
de la culture SRE
et de la sécurité psychologique
qui est embedée dans le film.
Pourquoi ne parlons pas de
ce qui est le sens de la sécurité psychologique
à l'aise?
Oui.
La sécurité psychologique
est vraiment importante pour moi.
Il signifie un peu de choses.
Je pense que le meilleur moyen
de décrire ce qui est la sécurité psychologique
pour moi, c'est de donner des exemples.
La sécurité psychologique pour moi
signifie que d'être
venu avec mes co-workers,
donc de partager
des parts et des détails
qui me permettent de me mettre
potentially dans un lit de blanche.
Je me dis que
je m'ai écrit quelque chose
qui ne travaillait pas bien.
Je suis capable de partager ça
sans la peur d'être accusée de quelque chose.
En quelque sorte, c'est un mindset de growth.
Nous sommes tous en train de devenir
des meilleurs individuels,
des co-workers et des enjeux.
Et chaque opportunité
que nous avons
dans la vie est une opportunité de se développer.
Je suis capable de être venu avec mes co-workers.
Je suis aussi
capable de donner des
opportunités de
développer mes co-workers.
Et je suis aussi
confortable de
recevoir des
co-workers.
Et je dois avoir ce space
de procéder à ces
feedbacks sans
en prendre le même temps.
Comme je l'ai dit
avant, nous avons des exemples
d'un d'entre nous
où nous pouvons prendre des risques
et faire des erreurs
sans la peur
d'être fier.
Je sais que je ne vais pas être fier
même si je vais faire des erreurs.
Nous étudions
les erreurs et les erreurs.
Et la seule façon de apprendre est de
essayer de nouvelles choses.
Et parfois, ces efforts ne vont pas
dans la bonne façon.
Plus, la sécurité psychologique
signifie que dans le cas rare
où quelque chose est en train de
être confortable socialement
ou techniquement, je sais
que j'ai quelqu'un que je peux
acheter qui n'est pas nécessairement HR.
Je sais que je peux aller à mon
manager et je peux partager
des choses très vulnérables et
je peux prendre des conflits
ou je peux même prendre des issues
techniques et je sais que mon
manager a mon bâtiment.
Mon manager va aller au bâtiment
pour moi et ça me rend
vraiment bien sûr.
Donc, en fait, je suis capable de
faire des opportunités où je peux me
donner. Je peux aussi croire
que mes co-workers se sentent de la même façon
et je sais que mon manager
est capable de donner cette sécurité
où, dans le cas où,
on dirait, les autres équipes ont des
issues ou peut-être elles
tentent de mettre en place des choses
que nous ne sommes pas confortables avec, je sais
que mon manager va nous faire un bâtiment
et nous protéger.
C'est vraiment un point d'aménagement
d'envers.
Je pense que
la sécurité psychologique
signifie que d'avoir le temps
de poser des questions, de donner
des opinions honnêtes, sans
ne pas se risquer que tout ça soit
détenu.
C'est vrai que ça a été arrivé
avant que la question
de la question qui est envers
nous a été complètement réveillée
et approchée.
Un de mes co-workers s'est dit que
il n'y avait pas de questions malades.
J'avais un bad habit
de quand je commençais, je me disais
que j'ai une question stupide
et il me disait
que c'est une bonne question
et ça me fait empouvoir.
Un autre
compagnie de sécurité psychologique
pour moi est
comment je suis percevée
comme un ingénieure.
C'est mon expérience
de temps dans ma université
et des doigts que j'ai eu
avant Google, que je n'étais pas
vraiment vu comme un ingénieure
mais je suis un ingénieure
des femmes et je me suis toujours
donné moins de tasks techniques
et mes idées ont eu moins de weight.
J'ai pris une classe d'ingénieure
de software et
ils ont essayé de
mettre toutes les documentations
à moi en pensant que je devais
faire des paroles
et ils me feraient travailler sur la code.
Il y a eu beaucoup de push back
pour me dire
que nous allions travailler sur ça.
Cette sort de
attitude et ces comportements
ont vraiment détaillé votre sens de belonging.
Quand tu es donnant
les moins glamouriques tasks
et tu n'es pas
comme les mêmes standings,
tu n'es pas comme un ingénieure.
Je me suis vraiment
apprécié que, à Google,
je suis toujours vu comme une équipe
d'un autre ingénieure.
Mes idées
sont sur leur propre mérité.
Je n'ai jamais, à Google,
pensé que c'est
ma idée ou
que c'est mal parce que c'est pour moi.
J'ai l'obligation
d'être honnête et respectée
comme un personne et
comme un ingénieur
qui aide à construire des équipes cohérentes.
Je me ressens
que les gens devraient toujours
être faits pour que ils puissent avoir
quelque chose d'utilisé pour contribuer.
Et un grand part
de la sécurité psychologique
à Google est que
tu es capable d'être
entièrement en train de faire le travail.
Et ce qui veut dire est que
par exemple, mon desk à work
est couvert dans des petits figurines de cat.
Beaucoup de ce qu'on donne
d'autres Google.
Je fais mon travail
à un desk qui me fait heureux
et qui me représente vraiment
moi comme un personne.
De pouvoir connecter avec mes co-workers
à un niveau personnel
et professionnel est un
très important part de
ce qui me fait vraiment proud
et heureux d'être Google.
C'est un important part de la sécurité psychologique
et de m'y belonging.
Je pense que nous avons entendu beaucoup aujourd'hui
de la
rôle
en itself et de la culture
de la SRE.
Un aspect qu'on ne pourrait pas toucher
est un peu
en particulier en tant que
des call, et le stress de la call
qui je ne suis pas intéressé
en comment tu es
en train de s'en aller
et de se réunir
au sein de la stress que la SRE
peut produire.
C'est
quelque chose qui a été plus difficile
avec la pandémie
et la Covid-19
parce que nous travaillions tous envers la maison
et la façon dont
je pense que beaucoup de gens
ont eu de stress après le travail
est de
prendre un temps envers leur commut
pour aller chez eux
et peut-être que tu es dans un espace différent
physique, donc tu peux
potentiellement laisser la stress
au sein de l'hôpital.
C'est comme ça que j'ai été
avec le stress de la call
et d'autres sortes de issues
de la SRE.
Mais, à la fin de la pandémie
quand nous allions travailler
chez eux, je travaillais
2 ans de l'hôpital
qui était 10 ans
de l'hôpital
et 15 ans de l'hôpital
où je serais
tous ces choses sont dans 20 ans de l'hôpital
de prendre 10 ans
et mon partenaire
m'a travaillé
et ça a causé beaucoup
d'invitées car
mon monde s'est fait
tomber et je n'avais pas
le temps de laisser la stress
quand je serais
au jour de travail.
C'était initialement très difficile
de séparer le travail
de la vie.
J'ai essayé de beber un peu de choses,
de vegeir sur la couche, de scroller sur TikTok,
sur Reddit, etc. et ça a
travaillé à un certain point.
Mais en fait, ce qui m'a terminé
de me séparer le travail de la vie
était de me séparer un pote.
C'est pas pourquoi j'ai un pote.
J'aurais voulu un pote pour longtemps,
mais c'était un des effets de
de la paix.
Parce que
les poteurs ont besoin
comme des humains
et ils sont
très communiqués
pour quand ils ont besoin d'une chose.
Et ça a fait un rôle
de comment je commence
et arrête le travail
à l'enquête du début
et du début de la journée.
Et par exemple, mon pote Biscotti
qui est super cute et maintenant elle est
en train de se couper
sur sa bede.
Mais elle commence
le travail avant tout, parce que je dois la marcher
en matin. Et je prends un 15, 20, 30 minutes
de marcher dans le parc où je suis
méditant,
en virtue de la marcher dans le parc.
Au lunch, je prends l'opportunité
d'avoir un temps au-delà,
d'avoir un fresh air, de venir pour le lunch,
pas de penser à la travail, mais de penser
à mon tour du parc et
mon défi avec Biscotti.
Au bout de la journée,
à 5h00,
à 5h00, elle vient de moi
et elle me pote sur la porte,
elle me démarre, elle s'y situe
à la desk et elle me dit
que le travail est terminé.
La temps de travail est maintenant.
On va au parc.
Et je réalise, ok, on va.
Oh, il y a
ce qu'elle a.
C'est à la queue.
C'est à la queue et c'est presque le matin.
Je dois lui prendre la minute.
Elle me donne des points
qui me rendent compte que c'est
le bout du travail.
Et par aller au bout du parc,
par aller en train de jouer avec elle,
je suis capable de ré-set-en
moi-même et de venir chez elle,
pas dans le mode travail, mais en mode vieille.
C'est beaucoup mieux que l'alarmée.
Je l'avoue totalement.
Surtout parce que
vous pouvez me faire tuer un alarm
mais vous ne pouvez pas
donner des ordres à un
je ne sais pas,
pour les nécessaires.
Ils nous ont besoin pour beaucoup.
La pandémie
était très difficile.
Je vivais dans une grosse ville
en Londres.
Les appartements sont très petites.
Et je pouvais
juste toucher ma desk avec ma porte
au bout de ma porte.
et j'ai pu juste me faire couler et faire travailler,
ce qui fait que c'est très difficile de ne pas juste travailler.
Les gens me sentaient de la pince au sein des heures de travail,
car mes heures de travail s'éteignent beaucoup de mes collègues en U.S.
et j'ai trouvé ça super facile de gagner le computant à l'intérieur,
de ne pas le répondre.
Et donc la solution là-bas
c'est de faire quelque chose qui n'a absolument rien à faire avec la technologie,
ce qui pour moi était de la cramer.
Je fais beaucoup de bordel, de la mouiller et de la cracheterie,
car il n'y a rien à faire avec le pince.
Les patterns sont toutes en papier, c'est le verre,
c'est les pinceaux, c'est la fabrique.
Quand vous faites attention à tous ces petits pièces
et en prenant la preuve d'être sure de que tout soit en bonne tension,
les collègues en bonne couleur et la bonne pattern.
C'est vraiment méditative,
juste en tournant et tournant et tournant.
Quand je suis en mode de la mode, je ne regarde pas mon téléphone.
Donc ça ne se distingue pas si tout le monde en monde est en train de me cacher.
Donc c'est vraiment très utile de
se faire de la technologie et de détaché entièrement.
Un autre chose que j'ai trouvé super utile pendant la pandémie
c'était de me maintenir les connections sociales.
Un peu de ce que j'ai compris quand les collègues finissent
c'était que mes collègues m'ont dit que je vais manger,
faire la thingue, aller au pub, tout ça.
Et évidemment, quand tous ces choses sont closes
et que vous ne pouvez pas voir ces gens,
ce n'est pas ce genre de signal de
de ne pas aller au bout du coude.
On a essayé de récréer ça vautuellement.
On avait des games de virtual où on jouait
sur le simulateur de Euro Truck,
ou on avait des pubs de virtual
et on avait un chat sur Google Meet.
C'était un moyen de
même si je suis sur un computé,
même si on ne peut pas être avec l'autre physically,
de ne pas se faire de la technologie
et de ne pas déclencher les notifications
c'est un point de salaire
et c'est quelque chose que je n'en fais pas.
Je pense que ce problème est compoundé
par le fait que beaucoup de nous sont vraiment passionnés
sur ce que nous faisons
et donc nous voulons continuer à travailler.
Je veux continuer à travailler
sur les problèmes que je sois carenée
et pour avoir des questions
Et donc c'est super facile, si la notification nous donne un point de vue dans le workspace,
c'est super facile de dire, oh, OK, oui, je vais juste faire ça pour une autre 5, 10, 15 heures.
Donc c'est vraiment important de être rigoureux de quand le travail finit,
et de vous tenir en compte, surtout dans la vie,
ou dans le monde de travail de chez vous, c'est extrêmement facile de révertir envers le workspace,
après le travail finit.
Oui, c'est incroyable que vous êtes super passionnés.
Il y a un million de moyens pour être passionnés sur la technologie
et faire des choses en technologie sans avoir à faire du travail,
parce que le grand chose pour être un ingénieur de la vie est que l'on est toujours en train de faire ces choses.
Je voudrais prendre le temps de dire que l'open source
est en train de faire des bonnes développements, des essorises, des gens,
et de faire des choses qui sont plus importants pour les gens.
Et c'est un bon moyen de être passionné sur la technologie,
de tenir en compte et de faire des choses,
et de ne pas avoir à faire de quoi que vous faites sur votre basis.
Je garde un packaging de génome, d'une opération en déviant,
et c'est super réplique de pouvoir contribuer à quelque chose que les autres utilisent,
et c'est un bon moyen de rencontrer les autres dans cette espèce de technologie
qui n'a rien à faire avec votre travail de jour-à-day.
Et donc, si vous voulez avoir une technologie pour être passionnés,
l'open source est un bon moyen de rencontrer les gens
et de les faire involvement en quelque chose qui n'a rien à faire avec votre travail.
Je voudrais aussi faire un autre point,
qui est que je fais des distinctions claires entre travail et vie,
et que je suis aussi en train de mettre des boundaries de temps.
Mais sur le côté de la flèche, je sais aussi que,
dans le cas où la vie s'éteint et une issue de pression,
je sais que j'ai l'obligation de prendre le temps de la journée pour les déjeuner.
Donc, en respectant mon fils,
le vêtement est seulement ouvert à 9h00 à 5h00,
ce qui est généralement quand les gens travaillent.
Je sais que je peux prendre deux heures au jour pour déjeuner un vêtement,
et ensuite aller en train de travailler,
en savoir que mes co-workers comprennent que la vie s'est déjeunée.
C'est un moment de plus en plus important.
Je pense que c'est un moment de plus en plus important.




Et c'est un moment de plus en plus important.
Et c'est un moment de plus en plus important.
Et c'est un moment de plus en plus important.
Et c'est un moment de plus en plus important.
C'est un moment de plus en plus important.