Break Things on Purpose Podcast Por Gremlin arte de portada

Break Things on Purpose

Break Things on Purpose

De: Gremlin
Escúchala gratis

A podcast about site reliability engineering (SRE); Chaos Engineering; and the people, processes, and tools used to build resilient systems. Sponsored by Gremlin. Find us on Twitter at @BTOPpod.©2018-2023 Gremlin
Episodios
  • Jason & Julie Take a Look Back

    Jason & Julie Take a Look Back
    Jul 12 2022

    Today Jason and Julie catch up and reflect on their favorite moments from Season 3, including unpopular opinions, chaos engineering, make or break moments in engineers’ careers, and more. They discuss the unique features of having established engineers and newer engineers on the show and what each one brings to the table, and they talk about some of their favorite “build” episodes, where engineers delve into the story of how they saw a need and then built a product to fulfill it. The conclude they conversation by sharing what’s next for Break Things on Purpose. See you next season!

    In this episode we cover:

    • Introduction to the episode and catching up with Jason and Julie (00:16)
    • Jason and Julie identify some of their favorite guests from the season (4:49)
    • The differences and advantages of having established engineers vs. newer engineers on the show (11:58)
    • Jason and Julie talk about their favorite “build” episodes (15:56)
    • What’s coming for Break Things on Purpose (21:20)


    Links Referenced:

    • January 11th, 2022 episode: https://www.gremlin.com/blog/podcast-break-things-on-purpose-unpopular-opinions/
    • Twitter: https://twitter.com/btoppod
    • gremlin.com/podcast: https://gremlin.com/podcast
    • loyaltyfreakmusic.com: https://loyaltyfreakmusic.com
    Más Menos
    23 m
  • Exploration and Resiliency with Mauricio Galdieri

    Exploration and Resiliency with Mauricio Galdieri
    Jun 28 2022
    In this episode, we cover:Mauricio talks about his background and his role at Pismo (1:14)Jason and Mauricio discuss tech and reliability with regards to financial institutions (5:59)Mauricio talks about the work he has done in Chaos Engineering with reliability (10:36)Mauricio discusses things he and his team have done to maximize success (19:44)Mauricio talks about new technologies his team has been utilizing (22:59)Links Referenced:Pismo: https://pismo.io/LinkedIn: https://www.linkedin.com/company/pismo/TranscriptMauricio: That’s why the name Cockroach, I guess, if there’s a [laugh] a world nuclear war here, all that will survive would be cockroaches in our client’s data. [laugh]. So, I guess that’s the gist of it.Jason: Welcome to Break Things on Purpose, a podcast about Chaos Engineering and reliability. In this episode, we chat with Mauricio Galdieri, a staff engineer at Pismo about testing versus exploration, reliability and resiliency, and the challenges of bringing new technologies to the financial sector.Jason: Welcome to the show.Mauricio: Hey, thank you. Welcome. Thanks for having me here, Jason.Jason: Yeah. So, Mauricio, you and I have chatted before in the past. We were at Chaos Conf, and you are part of a panel. So, I’m curious, I guess to kick things off, can you tell folks a little bit more about yourself and what you do at Pismo? And then we can maybe pick up from our conversations previously?Mauricio: Okay, awesome. I work as a staff engineer here at Pismo. I work in a squad called staff engineering squad, so we’re a bunch of—five squad engineers there. And we’re mostly responsible for coming up with new ways of using the existing technology, new technologies for us to have, and also standardize things like how we use those technologies here? How does it fit the whole processes we have here? And how does it fit in the pipelines we have here, also?And so, we do lots of documentation, lots of POCs, and try different things, and we talk to different people from different companies and see how they’re solving problems that we also have. So, this is basically our day-to-day activities here. Before that, well, I have a kind of a different story, I guess. Most people that work in this field, have a degree in something like a technical degree or something like that. But I actually graduated as an architect in urban planning, so I came from a completely different field.But I’ve always worked as a software developer since a long time ago, more than [laugh] willing to disclose. So, at that time when I started working with software development, I like to say that startups were called dotcoms that back then, so, [laugh] there was a lots of job opportunities back then, so I worked as a software developer at that time. And things evolved. I grew less and less as an architect and more as an engineer, so after I graduated, I started to look for a second degree, but on the more technical college, so I went to an engineering college and graduated as a system analyst.So, from then on, I’ve always worked as a software developer and never, never have done any house planning or house project or something like that. And I really doubt if I could do that right now [laugh] so I may be a lousy architect [in that sense 00:03:32]. But anyway, I’ve worked in different companies for both in private and public sectors. And I’ve worked with consultancy firms and so on. But just before I came to Pismo, I went working with a FinTech.So, this is where I was my first contact with the world of finance in a software context. Since then, I’ve digged deep into this industry, and here I am now working at Pismo, it’s for almost five years now.Jason: Wow. That quite a journey. And although it’s a unique journey, it’s also one that I feel like a lot of folks in tech come from different backgrounds and maybe haven’t gone down the traditional computer science route. With that said, you know, one of the things you mentioned FinTech. Can you give us a little bit of a description of Prismo, just so folks understand the company that you’re working at now?Mauricio: Oh, yeah. Well, Pismo, it’s a company that has about six years now. And we provide infrastructure for financial services. So, we’re not banks ourselves, but we provide the infrastructure for banks to build their financial projects with this. So basically, what we do is we manage accounts, we manage those accounts’ balances, we have connections with credit card networks, so we process—we’re also a credit card processor.We issue cards, although we’re not the issuer in this in the strict sense, but we issue cards here and manage all the lifecycle of those cards. And basically, that’s it. But we have a very broad offering of products, from account management to accounting management, and transactions management, and spending control limits and stuff. So, we have a very broad product portfolio. But basically, what we do is ...
    Más Menos
    31 m
  • Developer Advocacy and Innersource with Aaron Clark

    Developer Advocacy and Innersource with Aaron Clark
    Jun 14 2022
    In this episode, we cover:Aaron talks about starting out as a developer and the early stages of cloud development at RBC (1:05)Aaron discusses transitioning to developer advocacy (12:25)Aaron identifies successes he had in his early days of developer advocacy (20:35)Jason asks what it looks like to assist developers in achieving completion with long term maintenance projects, or “sustainable development” (25:40) Jason and Aaron discuss what “innersource” is and why it’s valuable in an organization (29:29)Aaron answers the question “how do you keep skills and knowledge up to date?” (33:55)Aaron talks about job opportunities at RBC (38:55)Links Referenced:Royal Bank of Canada: https://www.rbcroyalbank.comOpportunities at RBC: https://jobs.rbc.com/ca/enTranscriptAaron: And I guess some PM asked my boss, “So, Aaron doesn’t come to our platform status meetings, he doesn’t really take tickets, and he doesn’t take support rotation. What does Aaron do for the Cloud Platform Team?”Jason: [laugh].Jason: Welcome to Break Things on Purpose, a podcast about reliability, learning, and building better systems. In this episode, we talk with Aaron Clark, Director of Developer Advocacy at the Royal Bank of Canada. We chat with him about his journey from developer to advocate, the power of applying open-source principles within organizations—known as innersource—and his advice to keep learning.Jason: Welcome to the show, Aaron.Aaron: Thanks for having me, Jason. My name is Aaron Clark. I’m a developer advocate for cloud at RBC. That is the Royal Bank of Canada. And I’ve been at the bank for… well, since February 2010.Jason: So, when you first joined the bank, you were not a developer advocate, though?Aaron: Right. So, I have been in my current role since 2019. I’ve been part of the cloud program since 2017. Way back in 2010, I joined as a Java developer. So, my background in terms of being a developer is pretty much heavy on Java. Java and Spring Boot, now.I joined working on a bunch of Java applications within one of the many functions areas within the Royal Bank. The bank is gigantic. That’s kind of one of the things people sometimes struggle to grasp. It’s such a large organization. We’re something like 100,000… yeah, 100,000 employees, around 10,000 of that is in technology, so developers, developer adjacent roles like business analysts, and QE, and operations and support, and all of those roles.It’s a big organization. And that’s one of the interesting things to kind of grapple with when you join the organization. So, I joined in a group called Risk IT. We built solely internal-facing applications. I worked on a bunch of stuff in there.I’m kind of a generalist, where I have interest in all the DevOps things. I set up one of the very first Hudson servers in Risk—well, in the bank, but specifically in Risk—and I admin’ed it on the side because nobody else was doing it and it needed doing. After a few years of doing that and working on a bunch of different projects, I was occasionally just, “We need this project to succeed, to have a good foundation at the start, so Aaron, you’re on this project for six months and then you’re doing something different.” Which was really interesting. At the same time, I always worry about the problem where if you don’t stay on something for very long, you never learn the consequences of the poor decisions you may have made because you don’t have to deal with it.Jason: [laugh].Aaron: And that was like the flip side of, I hope I’m making good decisions here. It seemed to be pretty good, people seemed happy with it, but I always worry about that. Like, being in a role for a few years where you build something, and then it’s in production, and you’re running it and you’re dealing with, “Oh, I made this decision that seems like a good idea at the time. Turns out that’s a bad idea. Don’t do that next time.” You never learned that if you don’t stay in a role.When I was overall in Risk IT for four, almost five years, so I would work with a bunch of the teams who maybe stayed on this project, they’d come ask me questions. It’s like, I’m not gone gone. I’m just not working on that project for the next few months or whatever. And then I moved into another part of the organization, like, a sister group called Finance IT that runs kind of the—builds and runs the general ledger for the bank. Or at least for a part of capital markets.It gets fuzzy as the organization moves around. And groups combine and disperse and things like that. That group, I actually had some interesting stuff that was when I started working on more things like cloud, looking at cloud, the bank was starting to bring in cloud. So, I was still on the application development side, but I was interested in it. I had been to some conferences like OSCON, and started to hear about and learn about things like Docker, things like Kubernetes, ...
    Más Menos
    41 m
Todavía no hay opiniones